[perl #131593] [BUG][REGRESSION] Failure to sink values in for loops

[jn...@jnthn.net via RT]

On Sat, 17 Jun 2017 22:32:41 -0700, c...@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