From @ilyabelikin

Hi,
I compile 32444 and November die again :(

Our test_deeply use evals, but now it`s broken, example​:

my $b = eval '
  sub {
  @​_[0].say;
  for 1 { @​_[0].perl.say }
  }';

$b("Yay"); # Yay
  # undef

Ilya

From @jnthn

Hi,

Note that this isn't actually anything to do with eval, as originally
filed. You see exactly the same in​:

sub b {
  @​_[0].say;
  for 1 { @​_[0].perl.say }
};
b("Yay");

Changing ticket title to reflect this (still pondering the issue though).

Jonathan

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

From @jnthn

Patrick - giving this one to you, as I think it's related to or can be
addressed in your upcoming parameter refactor.

From @ronaldxs

sub b {
@​_[0].say;
for 1 { @​_[0].perl.say }
};
b("Yay");

Please note that as a (likely?) related problem, the code below results
in a Null PMC error​:
sub b { { say @​_[ 0 ] } }; b(5);

The initial problem can also be reproduced with "if"

sub b {
  @​_[0].say ;
  if 1 { @​_[ 0 ].say }
}
b('Yay');

Yielding the workaround below (which prints Yay twice as expected)​:
sub b {
  my @​a = @​_;
  @​a[0].say ;
  if 1 { @​a[ 0 ].say }
}
b('Yay');

pmichaud noted​:
There's still an issue in rakudo that any use of @​_ in a block makes it
act like a parameter.

From @kyleha

This is an automatically generated mail to inform you that tests are now available in t/t/spec/S06-signature/positional.t

From @moritz

Turns out that this ticket is bogus. @​_ is a placeholder variable just
like $^a, and thus always belongs to the inner block. If you don't want
that, simply use an explicit signature with a slurpy parameter on the
outer sub.

I have corrected the tests in S06-signature/positional.t to reflect this.

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