You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At first, in the case below, we assume when users define 'ambiguous' candidates, that is a mistake.
multi sub f(Int \a, Any \b) { }
multi sub f(Any \a, Int \b) { }
f(42, 42) # ambiguous
However, we then trust our users again, assuming they know textual ordering matters if tie-breaker applied.
multi sub f(Int \a where * > 0, Any \b) { }
multi sub f(Any \a, Int \b where * < 100) { }
f(42, 42) # the former is taken
Here is where users rarely arrive(really? around me people write code with a great variety of fantasies), but it shows what perl6 thinks of perl6 programmers.
Based on https://irclog.perlgeek.de/perl6/2017-11-30#i_15512831 , I arbitrarily put forward "Disable textual ordering as a tie-breaker in multi dispatch". The opposite is OK, that is enabling textual ordering even when users didn't use other tie-breaker, that means we believe perl6 programmers know what they do and be responsible for that, IMO.
The text was updated successfully, but these errors were encountered:
My vote is to follow the path of least resistance (and least user impact) and leave it as is. We're into our third year of claiming we're a stable language, so some things we'll have to accept and learn to live with.
Disabling isn't great. You'd have to try ALL of the available multies with wheres each time, which would be a performance impact and also would introduce a lot of unpredictability into programs. If the programmer didn't foresee a possible intersection where two of the wheres return True, they'll have a range of input for their program that simply crashes. That type of stuff is a lot harder to think about than ordering of the candidates in the source.
The opposite is OK, that is enabling textual ordering even when users didn't use other tie-breaker
I'm not 100% sure what you mean. Do you mean removing the ambiguity detection and just using the source ordering for candidates where we can tell with 100% certainty there'd be an ambiguity with 100% of input (something that isn't the case with where clauses).
That type of stuff is a lot harder to think about than ordering of the candidates in the source.
Agree with this. The most confusing point is why we disable textual ordering sometime. Now I approve of that we can die for ambiguous because there is "where we can tell with 100% certainty there'd be an ambiguity with 100% of input"
We're into our third year of claiming we're a stable language
Wish it being stable.
OK, I will attempt to accept that it is how perl6 works and learn it.
I'll close this issue a little later, if no one has other thoughts.
So here we are.
At first, in the case below, we assume when users define 'ambiguous' candidates, that is a mistake.
However, we then trust our users again, assuming they know textual ordering matters if tie-breaker applied.
Here is where users rarely arrive(really? around me people write code with a great variety of fantasies), but it shows what perl6 thinks of perl6 programmers.
Based on https://irclog.perlgeek.de/perl6/2017-11-30#i_15512831 , I arbitrarily put forward "Disable textual ordering as a tie-breaker in multi dispatch". The opposite is OK, that is enabling textual ordering even when users didn't use other tie-breaker, that means we believe perl6 programmers know what they do and be responsible for that, IMO.
The text was updated successfully, but these errors were encountered: