Re^4: Perl::Critic says don't modify $_ in list functions and other things

Beginning with perl 5.14, local $_ is a special case

Ah, I see, you're referring to RT#84774. Thanks for clarifying.

Update: Since the OP is no longer on 5.8.8, I think it's appropriate to mention that the local *_ workaround is no longer necessary.

Comment on Re^4: Perl::Critic says don't modify $_ in list functions and other things Select or Download Code

Replies are listed 'Best First'.
Re^5: Perl::Critic says don't modify $_ in list functions and other things by jcb (Vicar) on Jul 12, 2020 at 03:20 UTC
Fair enough; but her signature block still said that her Web host was on 5.8.8 when she posted the question and she did not clarify here until after we had had that discussion. While our questioner may no longer need to be concerned about that detail, the issue is still a concern for module authors (and really only module authors — scripts can simply avoid aliasing `$_` to read-only values when calling such "sensitive" routines) targeting backwards compatibility to perl versions before 5.14, and the workaround works in later versions, albeit with the caveat that you must collect your arguments into lexicals before localizing `_` or only use them again after exiting the block in which `_` was localized. I generally use the `my $foo = shift; my $bar = shift;` idiom to convert arguments to independent variables instead of leaving them as aliases, so localizing `*_` is not a problem — `@_` is empty well before that point.	[reply] [d/l] [select]
Re^6: Perl::Critic says don't modify $_ in list functions and other things by haukex (Bishop) on Jul 12, 2020 at 05:58 UTC
All true. Your initial post didn't mention the caveat that `@_` gets localized or that the `local *_` workaround is only needed for compatibility with Perls older than 5.14 (2011), so it's good this got cleared up.	[reply] [d/l] [select]


Syntactic Confectionery Delight
	PerlMonks