From @masak

<masak> m​: class Dog {}; sub foo(&block (Dog --> Bool)) { say "OH HAI"
}; foo(sub (Dog $x) { $x })
<camelia> rakudo-moar 315ec6​: OUTPUT«Too few positionals passed;
expected 1 argument but got 0 in sub-signature of parameter &block
[...]
<masak> what am I doing wrong here?
<masak> m​: class Dog {}; sub foo(&block​:(Dog --> Bool)) { say "OH HAI"
}; foo(sub (Dog $x) { $x })
<camelia> rakudo-moar 315ec6​: OUTPUT«===SORRY!===␤Cannot invoke this
object (REPR​: P6opaque, cs = 0)␤»
<masak> o.O
<FROGGS> m​: sub foo ( &cb (int) ) { }; sub bar (int) { }; foo(&bar) #
masak​: no idea why that fails
<camelia> rakudo-moar 315ec6​: OUTPUT«Too few positionals passed;
expected 1 argument but got 0 in sub-signature of parameter &cb [...]
<masak> FROGGS​: the error message doesn't make any sense.
<FROGGS> masak​: and that feature works in nativecall
<FROGGS> it is in its test suite for example
<masak> even curiouser.
<FROGGS> and it also fails under 2014.09
<FROGGS> (using star-m)

I am not 100% sure the `&block (Dog --> Bool)` form should work, or is
by spec. The `&block​:(Dog --> Bool)` form comes from S06​:1675.

From @masak

masak (>)​:

I am not 100% sure the `&block (Dog --> Bool)` form should work,
or is by spec. The `&block​:(Dog --> Bool)` form comes from S06​:1675.

<TimToady> at one point we required a : because of the ambiguity with sublists of parameters, but we already have a whitespace dep with @​foo[3,3] vs @​foo [$x,$y,$z], so having one for () is probably not terrible
* masak adds TimToady's comment to the ticket

From @hoelzro

On Sun Dec 07 07​:41​:52 2014, masak wrote​:

masak (>)​:

I am not 100% sure the `&block (Dog --> Bool)` form should work,
or is by spec. The `&block​:(Dog --> Bool)` form comes from S06​:1675.

<TimToady> at one point we required a : because of the ambiguity with
sublists of parameters, but we already have a whitespace dep with
@​foo[3,3] vs @​foo [$x,$y,$z], so having one for () is probably not
terrible
* masak adds TimToady's comment to the ticket

This bug has largely been resolved; closure parameters now parse correctly and work, except when used to decide between different multi candidates.

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

From @AlexDaniel

Yeah. It was resolved here I think​: (2014-12-08) rakudo/rakudo@fbc87d2

｢testneeded｣

On 2014-12-09 04​:54​:08, rob@​hoelz.ro wrote​:

On Sun Dec 07 07​:41​:52 2014, masak wrote​:

masak (>)​:

I am not 100% sure the `&block (Dog --> Bool)` form should work,
or is by spec. The `&block​:(Dog --> Bool)` form comes from
S06​:1675.

<TimToady> at one point we required a : because of the ambiguity with
sublists of parameters, but we already have a whitespace dep with
@​foo[3,3] vs @​foo [$x,$y,$z], so having one for () is probably not
terrible
* masak adds TimToady's comment to the ticket

This bug has largely been resolved; closure parameters now parse
correctly and work, except when used to decide between different multi
candidates.

From @zoffixznet

On Sat, 02 Dec 2017 05​:19​:45 -0800, alex.jakimenko@​gmail.com wrote​:

Yeah. It was resolved here I think​: (2014-12-08)
rakudo/rakudo@fbc87d2

｢testneeded｣

On 2014-12-09 04​:54​:08, rob@​hoelz.ro wrote​:

On Sun Dec 07 07​:41​:52 2014, masak wrote​:

masak (>)​:

I am not 100% sure the `&block (Dog --> Bool)` form should work,
or is by spec. The `&block​:(Dog --> Bool)` form comes from
S06​:1675.

<TimToady> at one point we required a : because of the ambiguity
with
sublists of parameters, but we already have a whitespace dep with
@​foo[3,3] vs @​foo [$x,$y,$z], so having one for () is probably not
terrible
* masak adds TimToady's comment to the ticket

This bug has largely been resolved; closure parameters now parse
correctly and work, except when used to decide between different
multi
candidates.

The form with space wasn't implemented.

It is now​: rakudo/rakudo@c0f99a393b
Tests for both forms​: Raku/roast@a31e4655e8

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

From @zoffixznet

On Mon, 11 Dec 2017 20​:30​:18 -0800, cpan@​zoffix.com wrote​:

The form with space wasn't implemented.

It is now​: rakudo/rakudo@c0f99a393b

Never mind. Decided to revert that form ( rakudo/rakudo@2f955d55e3 )

The `​:()` form is actually a Signature literal appended to the parameter, which is
nice and slick and makes lots of sense.

Adding slightly different syntax to do the same didn't feel right (since with Positionals, it means calling .Capture, while here it don't)