[perl #99942] [BUG] [+] @_ gives the wrong answer in Rakudo nom

[Carl Mäsak]

# New Ticket Created by  "Carl Mäsak" 
# Please include the string:  [perl #99942]
# in the subject line of all future correspondence about this issue. 
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=99942 >


<flussence> rakudo: sub add { [+]@_ }; say add(4, 5)
<p6eval> rakudo 6fd077: OUTPUT«2␤»
<flussence> :(
<benabik> rakudo: sub add { [+] @_ }; say add(4, 5)
<p6eval> rakudo 6fd077: OUTPUT«2␤»
<jnthn> er, why on earth did [+] @_ not work...
<flussence> b: sub add { [+]@_ }; say add(4, 5)
<p6eval> b 1b7dd1: OUTPUT«9␤»
<masak> nom: sub add { [+](@_) }; say add 4, 5
<p6eval> nom 6fd077: OUTPUT«2␤»
<benabik> nombug?
* masak submits rakudobug
<jnthn> nom: sub add(*@x) { [+] @x }; say add 4, 5
<p6eval> nom 6fd077: OUTPUT«9␤»
<jnthn> benabik: Yeah, that's my guess
<benabik> A bug in the implicit @_?
<TimToady> std: sub add { [+]@_ }; say add(4, 5)
<p6eval> std c22b2ee: OUTPUT«===SORRY!===␤Two terms
in a row [...]
<TimToady> space required after a reduce
<masak> fairy nuff.
<grondilu> rakudo: sub add { [+] @_ }; say add 1, 42
<p6eval> rakudo 6fd077: OUTPUT«2␤»
<benabik> Two bugs!  Parsing and @_ not working right in a reduce.
<jnthn> benabik: It's not reduce
<jnthn> benabik: It's something about the binding.
<TimToady> extra capture parens?
<jnthn> TimToady: Almost certainly a failure to set a flatten flag or
something like that.
<TimToady> not marked as flatten
<flussence> well I've managed to break both rakudo branches today,
that's an achievement :)

Let's ignore the TTIAR parsing error for now -- I think we have a
separate ticket for that somewhere in RT. There's something wrong with
the binding of @_.