On Tue Apr 21 03:50:19 2009, masak wrote:
> This might be in RT already, but I didn't find it, so...
>
> <ihrd> rakudo: multi foo (@a) { 1 }; multi foo ($a, %h?) { 2 }; say
> foo(<1 2 3>);
> <p6eval> rakudo 69b318: OUTPUT«Ambiguous dispatch to multi 'foo'.
> Ambiguous candidates had signatures::(Positional.new() @a):(Any $a,
> Associative.new() %h?) [...]
> * masak submits rakudobug
>
> As for arity, both methods can match. But the first candidate has a
> type constraint Positional on its first parameter, so it should be
> narrower than the second one, which doesn't. Therefore, the dispatch
> shouldn't be ambiguous, and the first candidate should be called.
The issue (as we saw elsewhere in this ticket's discussion) turned out
to be the optional parameter fooing up the narrowness analysis. The
sorter is a little smarter now and doesn't just say "oh noes, different
parameter count = tied" but instead tries to dis-ambiguate based upon
the number of parameters they both have available to compare between
them. This resolves the issue. Added this as a spectest, and the patch
went in as git 2731d20.
Thanks,
Jonathan
