<jnthn> rakudo: say Positional[Int] ~~ Any
<p6eval> rakudo e8f624: OUTPUT«1»
<jnthn> oh hmm
<jnthn> rakudo: say Any ~~ Positional[Int]
<p6eval> rakudo e8f624: OUTPUT«0»
<jnthn> But it kinda surprises me...
<jnthn> (I thought this was why Positional and Any were sorting to same
precedence level.)
<jnthn> rakudo: multi f($x) { 1 }; multi f(@x) { 2 }; say f(1); say f([1,2])
<p6eval> rakudo e8f624: OUTPUT«12»
<jnthn> oh hmm
<masak> strange that the above case resolves, but not the one in the RT
thread.
<jnthn> So the RT ticket I responded to actually brings up an issue
that's nothing to do with sigil based dispatch...
<jnthn> masak: Yeah.
<moritz_> jnthn: I think it's something else
<jnthn> rakudo: multi f($x, %h?) { 1 }; multi f(@x) { 2 }; say f(1); say
f([1,2])
<p6eval> rakudo 5c8015: OUTPUT«1Ambiguous dispatch to multi 'f'.
Ambiguous candidates had signatures::(Any $x, Associative.new()
%h?):(Positional.new() @x) [...]
<moritz_> not matching the sigil-implied type is one malus
<moritz_> and not filling up an optional parameter is also one malus
<jnthn> Ah, something to do with optional parameters...