From @zoffixznet

This a two part report​:

1) It appears in some cases a for loop doesn't sink stuff. Which causes, for example, a .map call to never be evaluated​:

  <Zoffix__> m​: sub foo($?) { ^2 .map​: &say }; foo() for 1
  <camelia> rakudo-moar c252b3​: ( no output )
  <Zoffix__> m​: sub foo($?) { ^2 .map​: &say }; foo().sink for 1
  <camelia> rakudo-moar c252b3​: OUTPUT​: «0␤1␤»

2) It actually works for the case when the sub is called as .&foo​:

  <Zoffix__> c​: 2017.05,HEAD sub foo($?) { ^2 .map​: &say }; foo() for 1
  <committable6> Zoffix__, ¦2017.05,HEAD(8074966)​: «»

  <Zoffix__> c​: 2017.05,HEAD sub foo($) { ^2 .map​: &say }; .&foo for 1
  <committable6> Zoffix__, ¦2017.05​: «0␤1» ¦HEAD(8074966)​: «»

This worked since summer of 2016, however, commit 9b0b9e made it not work again.

[1] rakudo/rakudo@9b0b9ef

From @jnthn

On Sat, 17 Jun 2017 22​:32​:41 -0700, cpan@​zoffix.com wrote​:

This a two part report​:

1) It appears in some cases a for loop doesn't sink stuff. Which
causes, for example, a .map call to never be evaluated​:

<Zoffix__> m​: sub foo($?) { ^2 .map​: &say }; foo() for 1
<camelia> rakudo-moar c252b3​: ( no output )
<Zoffix__> m​: sub foo($?) { ^2 .map​: &say }; foo().sink for 1
<camelia> rakudo-moar c252b3​: OUTPUT​: «0␤1␤»

It turns out that if did fix this, we'd break other things. Of note, we break​:

gather {
  take $_ => (1, 2, 3).Seq for (1…3), (1, (2, (3,))).Seq;
}

Because `take` returns the taken value. S32-list/flat.t is test containing this, for what it's worth. But it'd not surprise me in the least if such behavior is relied on in the wild.

2) It actually works for the case when the sub is called as .&foo​:

<Zoffix__> c​: 2017.05,HEAD sub foo($?) { ^2 .map​: &say }; foo() for 1
<committable6> Zoffix__, ¦2017.05,HEAD(8074966)​: «»

<Zoffix__> c​: 2017.05,HEAD sub foo($) { ^2 .map​: &say }; .&foo for 1
<committable6> Zoffix__, ¦2017.05​: «0␤1» ¦HEAD(8074966)​: «»

This worked since summer of 2016, however, commit 9b0b9e made it not
work again.

It's a bit curious that it works that way, but it was easy to restore the behavior. I'm figuring this got filed because something depends on it, so I've added tests so it won't stop working again in S04-statements/for.t and S04-statement-modifiers/for.t.

/jnthn

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

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

From @zoffixznet

On Mon, 19 Jun 2017 03​:09​:20 -0700, jnthn@​jnthn.net wrote​:

On Sat, 17 Jun 2017 22​:32​:41 -0700, cpan@​zoffix.com wrote​:
I'm figuring this got filed because something depends on
it

Yeah, it was found by Toaster as a regression in Concurrent​::File​::Find module.

Long live the Toaster \o/