From kristofbogaerts@gmail.com

p6​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>}, :assoc<left>); #
which one is correct?
rakudo e75a0a​: OUTPUT«duplicate named argument in call␤ in block
<anon> at /tmp/ohG08nWXj0​:1␤␤»
niecza v18-6-ge52d6c3​: OUTPUT«left␤» 21​:54​:05

p6​: sub s_s(*%n) { %n>>.say }; s_s(​:assoc<list>, :assoc<left>);
rakudo e75a0a, niecza v18-6-ge52d6c3​: OUTPUT«left␤»

jnthn​:
Rakudo has inconsistent behavior in that areas.
For non-flattened nameds it filters out the dupes
Flattened ones it can't do that, and Parrot barfs on dupe named args.

From @masak

<masak> TimToady​: ok, now I'm backlogging. I see a lot of trying stuff
out, but any bug is lost in the noise.
<masak> TimToady​: do you think you could rebase the bug on the present? ;)
<TimToady> r​: class A { submethod BUILD(​:$!v){ }; has $.v; method
new(*%_) { say 'OH HAI!'; nextwith(|%_, :v<test>); }; }; class B is A
{ has $.newfiled }; my $b = B.new(​:v('do you see me?'),​:newfiled(43));
say 'v​: ' ~ $b.v; say 'newfiled​: ' ~ $b.newfiled;
<camelia> rakudo-jvm 535d91​: OUTPUT«OH HAI!␤v​: test␤newfiled​: 43␤»
<camelia> ..rakudo-moar 535d91​: OUTPUT«OH HAI!␤v​: do you see me?␤newfiled​: 43␤»
<camelia> ..rakudo-parrot 535d91​: OUTPUT«OH HAI!␤duplicate named
argument in call␤ in method new at /tmp/tmpfile​:1␤ in block at
/tmp/tmpfile​:1␤␤»
<TimToady> that one
* masak peers at it
<masak> ah.
<masak> something is definitely up with that one. :)
* masak submits rakudobug
<masak> r​: class A { submethod BUILD(​:$!v){ }; has $.v; method
new(*%_) { nextwith(|%_, :v<bar>); }; }; class B is A {}; my $b =
B.new(​:v('foo')); say $b.v
<camelia> rakudo-jvm 535d91​: OUTPUT«bar␤»
<camelia> ..rakudo-parrot 535d91​: OUTPUT«duplicate named argument in
call␤ in method new at /tmp/tmpfile​:1␤ in block at
/tmp/tmpfile​:1␤␤»
<camelia> ..rakudo-moar 535d91​: OUTPUT«foo␤»
<masak> slightly minimaler.
<timotimo> hooray
<diakopter> wat :)
<masak> anyway, in the above WAT, I think Parrot is obviously wrong,
so let's drop that one out of the contest.
<masak> between the other two, JVM makes the most sense to me.

At least two of them is wrong. I think rakudo-jvm is right, above.

From @coke

On Thu Jun 07 13​:07​:46 2012, kristofbogaerts@​gmail.com wrote​:

p6​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>}, :assoc<left>); #
which one is correct?
rakudo e75a0a​: OUTPUT«duplicate named argument in call␤ in block
<anon> at /tmp/ohG08nWXj0​:1␤␤»
niecza v18-6-ge52d6c3​: OUTPUT«left␤» 21​:54​:05

p6​: sub s_s(*%n) { %n>>.say }; s_s(​:assoc<list>, :assoc<left>);
rakudo e75a0a, niecza v18-6-ge52d6c3​: OUTPUT«left␤»

jnthn​:
Rakudo has inconsistent behavior in that areas.
For non-flattened nameds it filters out the dupes
Flattened ones it can't do that, and Parrot barfs on dupe named args.

16​:11 < [Coke]> p6​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>},
  :assoc<left>);
16​:11 <+camelia> rakudo-jvm bc6a32​: OUTPUT«(timeout)»
16​:11 <+camelia> ..niecza v24-109-g48a8de3​: OUTPUT«left␤»
16​:11 <+camelia> ..rakudo-parrot bc6a32​: OUTPUT«duplicate named argument in
  call␤ in block at /tmp/tmpfile​:1␤␤»
16​:11 <+camelia> ..rakudo-moar bc6a32​: OUTPUT«list␤»
16​:12 < [Coke]> ... wow, it's getting worse.

--
Will "Coke" Coleda

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

From @coke

On Thu Aug 21 13​:12​:32 2014, coke wrote​:

On Thu Jun 07 13​:07​:46 2012, kristofbogaerts@​gmail.com wrote​:

p6​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>}, :assoc<left>); #
which one is correct?
rakudo e75a0a​: OUTPUT«duplicate named argument in call␤ in block
<anon> at /tmp/ohG08nWXj0​:1␤␤»
niecza v18-6-ge52d6c3​: OUTPUT«left␤» 21​:54​:05

p6​: sub s_s(*%n) { %n>>.say }; s_s(​:assoc<list>, :assoc<left>);
rakudo e75a0a, niecza v18-6-ge52d6c3​: OUTPUT«left␤»

jnthn​:
Rakudo has inconsistent behavior in that areas.
For non-flattened nameds it filters out the dupes
Flattened ones it can't do that, and Parrot barfs on dupe named args.

16​:11 < [Coke]> p6​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>},
:assoc<left>);
16​:11 <+camelia> rakudo-jvm bc6a32​: OUTPUT«(timeout)»
16​:11 <+camelia> ..niecza v24-109-g48a8de3​: OUTPUT«left␤»
16​:11 <+camelia> ..rakudo-parrot bc6a32​: OUTPUT«duplicate named argument in
call␤ in block at /tmp/tmpfile​:1␤␤»
16​:11 <+camelia> ..rakudo-moar bc6a32​: OUTPUT«list␤»
16​:12 < [Coke]> ... wow, it's getting worse.

Looks better, but I think we need jvm & moar to agree here.

06​:12 < [Coke]> r​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>},​:assoc<left>);
06​:12 < GLRelia> rakudo-moar 05ce1e​: OUTPUT«list␤»
06​:12 <+camelia> rakudo-jvm 5fb81f​: OUTPUT«left␤»
06​:12 <+camelia> ..rakudo-moar 5fb81f​: OUTPUT«list␤»

06​:16 < [Coke]> when flattening duplicate named args, does the one that gets picked matter?
06​:17 < moritz> [Coke]​: iirc the last one wins

--
Will "Coke" Coleda

From @skids

This seems to be simply a matter of a shared method not being
presented as if it were a copy of, rather than the same as,
the parent class's definition, nothing special about .new.

If the subclass does not have its own method definition, the
superclass is called directly, so next* looks and says it is
already at the top of the tree, and does nothing.

$ perl6 -e 'use nqp; class A { method foo { say "OHAI " ~ self.^name ~ nqp​::getattr(&?ROUTINE, Routine, "\$!package").^name; nextsame;} }; class B is A { method foo { say "OHAI " ~ self.^name ~ nqp​::getattr(&?ROUTINE, Routine, "\$!package").^name ; nextsame;} }; B.new.foo();'
OHAI BB
OHAI BA
$ perl6 -e 'use nqp; class A { method foo { say "OHAI " ~ self.^name ~ nqp​::getattr(&?ROUTINE, Routine, "\$!package").^name; nextsame;} }; class B is A { }; B.new.foo();'
OHAI BA

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

From @jnthn

On Sun Feb 02 13​:28​:22 2014, masak wrote​:

<masak> TimToady​: ok, now I'm backlogging. I see a lot of trying stuff
out, but any bug is lost in the noise.
<masak> TimToady​: do you think you could rebase the bug on the
present? ;)
<TimToady> r​: class A { submethod BUILD(​:$!v){ }; has $.v; method
new(*%_) { say 'OH HAI!'; nextwith(|%_, :v<test>); }; }; class B is A
{ has $.newfiled }; my $b = B.new(​:v('do you see me?'),​:newfiled(43));
say 'v​: ' ~ $b.v; say 'newfiled​: ' ~ $b.newfiled;
<camelia> rakudo-jvm 535d91​: OUTPUT«OH HAI!␤v​: test␤newfiled​: 43␤»
<camelia> ..rakudo-moar 535d91​: OUTPUT«OH HAI!␤v​: do you see
me?␤newfiled​: 43␤»
<camelia> ..rakudo-parrot 535d91​: OUTPUT«OH HAI!␤duplicate named
argument in call␤ in method new at /tmp/tmpfile​:1␤ in block at
/tmp/tmpfile​:1␤␤»
<TimToady> that one
* masak peers at it
<masak> ah.
<masak> something is definitely up with that one. :)
* masak submits rakudobug
<masak> r​: class A { submethod BUILD(​:$!v){ }; has $.v; method
new(*%_) { nextwith(|%_, :v<bar>); }; }; class B is A {}; my $b =
B.new(​:v('foo')); say $b.v
<camelia> rakudo-jvm 535d91​: OUTPUT«bar␤»
<camelia> ..rakudo-parrot 535d91​: OUTPUT«duplicate named argument in
call␤ in method new at /tmp/tmpfile​:1␤ in block at
/tmp/tmpfile​:1␤␤»
<camelia> ..rakudo-moar 535d91​: OUTPUT«foo␤»
<masak> slightly minimaler.
<timotimo> hooray
<diakopter> wat :)
<masak> anyway, in the above WAT, I think Parrot is obviously wrong,
so let's drop that one out of the contest.
<masak> between the other two, JVM makes the most sense to me.

At least two of them is wrong. I think rakudo-jvm is right, above.

This isn't actually anything to do with nextwith, but in fact the named arg flattening order bug in disguise​:

17​:11 < jnthn> r​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>},​:assoc<left>);
17​:11 < camelia> rakudo-moar 019a7f​: OUTPUT«list␤»
17​:11 < camelia> ..rakudo-jvm f0c6a0​: OUTPUT«left␤»

So, merging it into that ticket.

/jnthn

From @jnthn

On Sat Aug 29 03​:18​:43 2015, coke wrote​:

On Thu Aug 21 13​:12​:32 2014, coke wrote​:

On Thu Jun 07 13​:07​:46 2012, kristofbogaerts@​gmail.com wrote​:

p6​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>}, :assoc<left>);
#
which one is correct?
rakudo e75a0a​: OUTPUT«duplicate named argument in call␤ in block
<anon> at /tmp/ohG08nWXj0​:1␤␤»
niecza v18-6-ge52d6c3​: OUTPUT«left␤» 21​:54​:05

p6​: sub s_s(*%n) { %n>>.say }; s_s(​:assoc<list>, :assoc<left>);
rakudo e75a0a, niecza v18-6-ge52d6c3​: OUTPUT«left␤»

jnthn​:
Rakudo has inconsistent behavior in that areas.
For non-flattened nameds it filters out the dupes
Flattened ones it can't do that, and Parrot barfs on dupe named
args.

16​:11 < [Coke]> p6​: sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>},
:assoc<left>);
16​:11 <+camelia> rakudo-jvm bc6a32​: OUTPUT«(timeout)»
16​:11 <+camelia> ..niecza v24-109-g48a8de3​: OUTPUT«left␤»
16​:11 <+camelia> ..rakudo-parrot bc6a32​: OUTPUT«duplicate named
argument in
call␤ in block at /tmp/tmpfile​:1␤␤»
16​:11 <+camelia> ..rakudo-moar bc6a32​: OUTPUT«list␤»
16​:12 < [Coke]> ... wow, it's getting worse.

Looks better, but I think we need jvm & moar to agree here.

06​:12 < [Coke]> r​: sub s_s(*%n) { %n>>.say };
s_s(|{​:assoc<list>},​:assoc<left>);
06​:12 < GLRelia> rakudo-moar 05ce1e​: OUTPUT«list␤»
06​:12 <+camelia> rakudo-jvm 5fb81f​: OUTPUT«left␤»
06​:12 <+camelia> ..rakudo-moar 5fb81f​: OUTPUT«list␤»

06​:16 < [Coke]> when flattening duplicate named args, does the one
that gets picked matter?
06​:17 < moritz> [Coke]​: iirc the last one wins

Fixed now​:

$ perl6-m -e "sub s_s(*%n) { %n>>.say }; s_s(|{​:assoc<list>},​:assoc<left>);" left

Tests in S06-signature/named-parameters.t.

/jnthn

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