From @Util

On Rakudo Star 2010-10, this code works as expected, outputting "42\n"
:
  multi sub Bar ( ) { return 42 };
  say Bar();
This code should give the same output (and *does* on Pugs)​:
  multi sub Bar ( ) { return 42 };
  multi sub Bar (​:$baz!) { return $baz };
  say Bar();
Instead, Rakudo dies on this error​:
  No applicable candidates found to dispatch to for 'Bar'. Available
candidates are​:
  :()
  :(Any :baz($baz)!)

IMHO, required named parameters should default to being part of the
longname.
In any case, the current behavior looks like a bug.

From http://irclog.perlgeek.de/perl6/2010-10-31#i_2956591
  < Util> perl6​: say Bar(); multi sub Bar ( ) { return 42 };
  <+p6eval> pugs, rakudo 5f5bae​: OUTPUT<<42NL>>
  < Util> perl6​: say Bar(); multi sub Bar ( ) { return 42 }; multi
sub Bar (​:$baz!) { return $baz };
  <+p6eval> rakudo 5f5bae​: OUTPUT<<No applicable candidates found to
dispatch to for 'Bar'. Available candidates
  are​:NL​:()NL​:(Any :baz($baz)!)NLNL in main program body
at line 22​:/tmp/UGNiomLxSCNL>>
  <+p6eval> ..pugs​: OUTPUT<<42NL>>
  < Util> In Rakudo, why is the second declaration interfering?
  < masak> looks like a bug to me.
  < masak> ...possibly reported already.
  < sorear> Perl 6.0 is not required to support multiple dispatch
with named parameters
  < masak> but I thought Rakudo did.
  < jnthn> No
  < jnthn> Well, it doesn't consider them other than as constraints.
  < jnthn> e.g. if one is required it's a constraint.
  < Util> sorear​: it is more than just a named parm; it is a
*required* named parm.
  Shouldn't that make it part of the dispatch?
  < masak> apparently, it's difficult to do that in practice.
  < jnthn> Rakudo already considered required named params as
constraints.
  < jnthn> Otherwise a bunch of our trait_mods would never work.
  < jnthn> It even has an optimization for the
single-required-named-param case. :-)
  < jnthn> Util​: Can you file a ticket?
  < jnthn> That looks like a bug to me. :S
  < Util> Will file rakudobug. Thanks, all!
  < jnthn> Util++
  < jnthn> But it turns out to be a silly thinko. :-)
  < jnthn> Somewhere in that little file, perl6multisub.pmc :-)
  < jnthn> masak​: There's another one in RT that I think is distinct
from this but may end up related in the end.
  < masak> jnthn​: ok. I didn't find anything about required nameds.
  < jnthn> masak​: I think it was about an argless candidate.
  < jnthn> Or at least, that's the common dominator between these
two.

--
Hope this helps,
Bruce Gray (Util)

From @coke

On Sun Oct 31 16​:38​:58 2010, util wrote​:

On Rakudo Star 2010-10, this code works as expected, outputting "42\n"
:
multi sub Bar ( ) { return 42 };
say Bar();
This code should give the same output (and *does* on Pugs)​:
multi sub Bar ( ) { return 42 };
multi sub Bar (​:$baz!) { return $baz };
say Bar();
Instead, Rakudo dies on this error​:
No applicable candidates found to dispatch to for 'Bar'. Available
candidates are​:
:()
:(Any :baz($baz)!)

Fixed​:

17​:07 < [Coke]> rakudo​: multi sub Bar ( ) { return 42 }; multi sub Bar
(​:$baz!)
  { return $baz }; say Bar();
17​:07 <+p6eval> rakudo 33f1cf​: OUTPUT«42␤»

Closable with tests.

IMHO, required named parameters should default to being part of the
longname.
In any case, the current behavior looks like a bug.

From http://irclog.perlgeek.de/perl6/2010-10-31#i_2956591
< Util> perl6​: say Bar(); multi sub Bar ( ) { return 42 };
<+p6eval> pugs, rakudo 5f5bae​: OUTPUT<<42NL>>
< Util> perl6​: say Bar(); multi sub Bar ( ) { return 42 }; multi
sub Bar (​:$baz!) { return $baz };
<+p6eval> rakudo 5f5bae​: OUTPUT<<No applicable candidates found to
dispatch to for 'Bar'. Available candidates
are​:NL​:()NL​:(Any :baz($baz)!)NLNL in main program body
at line 22​:/tmp/UGNiomLxSCNL>>
<+p6eval> ..pugs​: OUTPUT<<42NL>>
< Util> In Rakudo, why is the second declaration interfering?
< masak> looks like a bug to me.
< masak> ...possibly reported already.
< sorear> Perl 6.0 is not required to support multiple dispatch
with named parameters
< masak> but I thought Rakudo did.
< jnthn> No
< jnthn> Well, it doesn't consider them other than as constraints.
< jnthn> e.g. if one is required it's a constraint.
< Util> sorear​: it is more than just a named parm; it is a
*required* named parm.
Shouldn't that make it part of the dispatch?
< masak> apparently, it's difficult to do that in practice.
< jnthn> Rakudo already considered required named params as
constraints.
< jnthn> Otherwise a bunch of our trait_mods would never work.
< jnthn> It even has an optimization for the
single-required-named-param case. :-)
< jnthn> Util​: Can you file a ticket?
< jnthn> That looks like a bug to me. :S
< Util> Will file rakudobug. Thanks, all!
< jnthn> Util++
< jnthn> But it turns out to be a silly thinko. :-)
< jnthn> Somewhere in that little file, perl6multisub.pmc :-)
< jnthn> masak​: There's another one in RT that I think is distinct
from this but may end up related in the end.
< masak> jnthn​: ok. I didn't find anything about required nameds.
< jnthn> masak​: I think it was about an argless candidate.
< jnthn> Or at least, that's the common dominator between these
two.

--
Will "Coke" Coleda

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

From @moritz

Now tested in S06-multi/positional-vs-named.t

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