I have to admit I'm not too much concerned about aliasing in for-each-loops, because they have a limited scope.

Loosing the overview about aliases in nested for-eaches implies bad coding practice resp. the need for refactoring.

So I'm more concentrating on the @_ aliases of subs, the possible effects are not limited to the sub.

Let's suppose a sub Package_A::trim($a) which uses call-by-reference to delete leading and trailing whitespaces.

Another sub Package_B::report() might create a report, and needs to trim the entries:

sub report {
  trim($_) for @_;
  return sprintf "...",@_;
}
[download]

Some code in Package_C calls report() and passes occasionally a read-only value.

Now depending on the implementation of trim() the code might

a) die with "modification of read-only ..." or

b) continue but silently fail to delete the whitespaces.

That's why I think there should be at least a warning in case b.

> I don't see a point to a switch whose sole purpose is to break working code.

I don't understand why a warning would break existing code.

In general:

And I don't see a better coding practice, except avoiding subs like trim() using side-effects by manipulation $_[]

Clearly the author of report() doesn't expect read-only arguments, but since Perl5 doesn't have signatures like in Perl6 he can't easily enforce them.

He could rely on the implementation of trim which throws an error in case a). But after the author of Package_A switches to implementation b) of trim() the functionality of Package_B is broken.

And the different test-suites of packages A,B and C do not report any problem. I hope it's understandable now why aliasing in subs bothers me more than in for-eaches.

PS: Sorry for the delay, quite busy ATM.