<cognominal> rakudo: multi sub f(@p, Range $r? ) { say 1 }; multi sub f([],
Range $r) { say 2 };
f([], 1..2);
<p6eval> rakudo d9a5ac: OUTPUT«2»
<cognominal> rakudo: multi sub f(@p, Range $r?, Bool :$mod ) { say 1 }; multi
sub f([], Range
$r) { say 2 }; f([], 1..2);
<p6eval> rakudo d9a5ac: OUTPUT«Ambiguous dispatch to multi 'f'. Ambiguous
candidates had
signatures::(@p, Range $r?, Bool :mod($mod)):(Positional (), Range $r) [...]
<cognominal> [...] I still don't understand the behavior in my last paste.
<jnthn> cognominal: I do
<jnthn> cognominal: Though not quite sure if it's desirable...
<jnthn> But I get it's to do with the named param
<jnthn> As I've said before, if you're going to want named params to influence
dispatch, you
need to mark them as required to not end up in that candidate.
<masak> jnthn: but how does the addition of a named param cause two
non-conflicting
candidates to suddenly conflict, as above? :/
<masak> I'm definitely not sure that's desirable.
<jnthn> masak: I'm not sure if that's the whole story there
<masak> that's what I see.
<jnthn> Oh, wait...that's all that was added
<jnthn> Oh
* masak adds that to the ticket
<jnthn> I bet it's because it says "oh, there's a named parameter there, so I'd
best make sure
the signautre is bindable"
<jnthn> And then both have constraints
<jnthn> Both are satisfied
<jnthn> And thus conflict
<jnthn> The spec probably wants "first wins" though
<jnthn> But I don't like that.
<jnthn> Anyway, I'm not especially surprised by the conflict.
<mathw> Why wouldn't it amke sure the signature was bindable without the named
parameter?
<jnthn> mathw: It doesn't have to go and do a full bindability check there
<jnthn> mathw: It can go purely on arity and types
<jnthn> mathw: It's only when you have where clauses, sub-signatures or named
parameters
that it then treats bindability as needed for a tie-break.
<mathw> okay yes that makes sense
<mathw> I was struggling with the idea that adding an optional named param was
changing the
resolution order in a sense
<mathw> but then I realised that of course it can
<mathw> because you've changed the signature
<mathw> although I'd still kind of expect the [] to cause the two-param version
to bind more
tightly there
<jnthn> Nope
<mathw> but that's an intuitive, non-rigorous thought
<jnthn> There's no such thing as a "better constraint"
