From @lizmat

[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)
[13​:23​:12] <lizmat> colomon​: how could that not not be a bug ?
[13​:24​:13] <FROGGS> n​: multi sub a ($a, :$foo) { say "with named $a $foo" }; multi sub a ($a) { say "without named $a" }; a("bar") # checking niecza
[13​:24​:15] <+camelia> niecza v24-95-ga6d4c5f​: OUTPUT«without named bar␤»
[13​:24​:43] <lizmat> rn​: multi sub a ($a, :$foo) { say "with named $a $foo" }; multi sub a ($a) { say "without named $a" }; a("bar")
[13​:24​:48] <+camelia> rakudo c5ba78​: OUTPUT«use of uninitialized value of type Any in string context in sub a at /tmp/8jPolJRUuH​:1␤␤with named bar ␤»
[13​:24​:48] <+camelia> ..niecza v24-95-ga6d4c5f​: OUTPUT«without named bar␤»
[13​:25​:06] <lizmat> I think this calls for either a rakudo or niecza bug
[13​:25​:07] <colomon> lizmat​: I would (possibly naively) expect the most specific multi to win. but the least specific multi is winning. my default assumption is bug.
[13​:25​:18] <FROGGS> lizmat​: I think it should complain about an ambigious all
[13​:25​:21] <FROGGS> call*
[13​:25​:25] <lizmat> that at least
[13​:25​:47] <lizmat> but how can "no named parameters" not be narrower than "any named parameters" ?
[13​:25​:51] <colomon> seems like we've thought up three possible behaviors, and rakudo is doing *none* of them.
[13​:26​:17] lizmat submits rakudobug

From @lizmat

On Sep 21, 2013, at 1​:28 PM, Elizabeth Mattijsen (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Elizabeth Mattijsen
# Please include the string​: [perl #​119929]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=119929 >

[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)
[13​:23​:12] <lizmat> colomon​: how could that not not be a bug ?
[13​:24​:13] <FROGGS> n​: multi sub a ($a, :$foo) { say "with named $a $foo" }; multi sub a ($a) { say "without named $a" }; a("bar") # checking niecza
[13​:24​:15] <+camelia> niecza v24-95-ga6d4c5f​: OUTPUT«without named bar␤»
[13​:24​:43] <lizmat> rn​: multi sub a ($a, :$foo) { say "with named $a $foo" }; multi sub a ($a) { say "without named $a" }; a("bar")
[13​:24​:48] <+camelia> rakudo c5ba78​: OUTPUT«use of uninitialized value of type Any in string context in sub a at /tmp/8jPolJRUuH​:1␤␤with named bar ␤»
[13​:24​:48] <+camelia> ..niecza v24-95-ga6d4c5f​: OUTPUT«without named bar␤»
[13​:25​:06] <lizmat> I think this calls for either a rakudo or niecza bug
[13​:25​:07] <colomon> lizmat​: I would (possibly naively) expect the most specific multi to win. but the least specific multi is winning. my default assumption is bug.
[13​:25​:18] <FROGGS> lizmat​: I think it should complain about an ambigious all
[13​:25​:21] <FROGGS> call*
[13​:25​:25] <lizmat> that at least
[13​:25​:47] <lizmat> but how can "no named parameters" not be narrower than "any named parameters" ?
[13​:25​:51] <colomon> seems like we've thought up three possible behaviors, and rakudo is doing *none* of them.
[13​:26​:17] lizmat submits rakudobug

Additionally​:

[13​:27​:02] colomon goes looking in roast
[13​:29​:15] <colomon> positional-vs-named.t only tests named parameters declared with exclamation points.
[13​:29​:26] <colomon> rn​: multi sub a ($a, :$foo!) { say "with named $a $foo" }; multi sub a ($a) { say "without named $a" }; a("bar")
[13​:29​:29] <+camelia> rakudo c5ba78, niecza v24-95-ga6d4c5f​: OUTPUT«without named bar␤»
[13​:30​:21] <lizmat> colomon​: unfortunately, I need *all* named params to be optional :-(
[13​:30​:40] <colomon> rn​: multi sub a ($a, :$foo?) { say "with named $a $foo" }; multi sub a ($a) { say "without named $a" }; a("bar")
[13​:30​:43] <+camelia> niecza v24-95-ga6d4c5f​: OUTPUT«without named bar␤»
[13​:30​:43] <+camelia> ..rakudo c5ba78​: OUTPUT«use of uninitialized value of type Any in string context in sub a at /tmp/B1iLu772zp​:1␤␤with named bar ␤»
[13​:33​:06] <colomon> lizmat​: while I agree there's something wonky going on here, do you really require two different subs? should a("bar") and a("bar", foo=>False) do different things?
[13​:33​:25] <lizmat> well, this is about {} and [] accesses
[13​:33​:46] <lizmat> if there are no named params specified, I would like it to select the quickest sub
[13​:34​:08] <lizmat> *now* I have to check all of the passed named parameters for *each* bare [] and {} access
[13​:34​:33] <lizmat> aka​: $delete & $exists & $kv & $p & $k & $v === $default
[13​:34​:33] <lizmat> ?? SELF.at_key($key)
[13​:34​:49] <lizmat> rather than just SELF.at_key($key)
[13​:35​:44] <colomon> I'm not sure forcing rakudo to figure it out with a multi will be a performance win there.
[13​:36​:01] <lizmat> it's about being able to do this at compile time
[13​:36​:08] <colomon> I suppose if you have to have a multi anyway, it's not a bit deal...
[13​:36​:11] <lizmat> so each {} and [] access doesn't have to go through a multi
[13​:36​:21] <lizmat> but can be optimized to take the right one right away
[13​:37​:17] <jercos> but that's sort of a perfect-world thing.
[14​:02​:43] <timotimo> i think foo($a, :$foo) is narrower than foo($a), because foo($a) is really foo($a, *%)
[14​:04​:18] <lizmat> timotimo​: then there should be an attribute "is nonamed" or something like that
[14​:04​:46] <lizmat> because we will need the selection of the simplest candidate for speed
[14​:04​:47] <timotimo> hmm
[14​:04​:51] <timotimo> yes.

From @jnthn

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.

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'