New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure to sink values in for loops #6337
Comments
From @zoffixznetThis 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 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 <Zoffix__> c: 2017.05,HEAD sub foo($) { ^2 .map: &say }; .&foo for 1 This worked since summer of 2016, however, commit 9b0b9e made it not work again. |
From @jnthnOn Sat, 17 Jun 2017 22:32:41 -0700, cpan@zoffix.com wrote:
It turns out that if did fix this, we'd break other things. Of note, we break: gather { 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.
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 @zoffixznetOn Mon, 19 Jun 2017 03:09:20 -0700, jnthn@jnthn.net wrote:
Yeah, it was found by Toaster as a regression in Concurrent::File::Find module. Long live the Toaster \o/ |
Migrated from rt.perl.org#131593 (status was 'resolved')
Searchable as RT131593$
The text was updated successfully, but these errors were encountered: