On Sat Sep 21 04:28:25 2013, elizabeth wrote:
> [13:18:06] <lizmat> r: multi sub a ($a) { say "without named" };
> multi sub a ($a, :$foo) { say "with named" }; a("bar") # bug or
> feature ??
> [13:18:07] <+camelia> rakudo c5ba78: OUTPUT«with named»
> [13:18:25] <lizmat> given 2 candidates, one without named, and
> one with an optional named
> [13:18:42] <colomon> lizmat: how could that not be a bug?
> [13:18:51] <lizmat> is it right that the candidate with the
> optional named parameter is selected even if there is no named
> parameter given ?
> [13:19:14] <masak> lizmat: I think in this case, it comes down
> to ordering.
> [13:19:22] <masak> lizmat: I'd need to re-read S06 to be sure.
> [13:19:36] <masak> lizmat: but if it comes down to ordering, I
> still think the first one should win.
> [13:20:15] <lizmat> r: multi sub a ($a, :$foo) { say "with named"
> }; multi sub a ($a) { say "without named" }; a("bar") # which one
> wins ?
> [13:20:16] <+camelia> rakudo c5ba78: OUTPUT«with named»
> [13:20:32] <lizmat> seems to not be an order thing here
> [13:21:02] <lizmat> seems the candidate without named params is
> always ignored (to me, at least)
Named parameters do not participate in multi-dispatch in the same way that
positional parameters do. Of note, the presence of named parameters works the
same way that `where` clauses and sub-signatures do: they serve as an
additional constraint to be met. All else being equal with the positionals,
this constraint makes the candidate with nameds therefore narrower, and thus
considered first and at a separate level to the other candidate with no named
args.
Since the candidate then goes on to match (because the named parameter is
optional), it is picked. Since it is narrower, there is no ambiguity with the
candidate without a named parameter. Making the named parameter required would,
of course, reject the candidate. That's how most trait_mod dispatches work.
A test covering this is now in S06-multi/positional-vs-named.t.
