Ahh, silly me, I forgot context. So my examples would have to be either

my $stuff;
for(scalar something()) {
    # ...
    $stuff = $_;
}
[download]

vs

my $stuff = something();
for($stuff) {
    # ...
}
[download]

or

my $stuff;
for(something()) {
    # ...
    $stuff = $_;
}
[download]

vs

my ($stuff) = something();
for($stuff) {
    # ...
}
[download]

Thanks for the correction.

For an example on Lvalues, see Abigail-II's inside out objects technique. In retrospect, it seems silly to even field that argument, since a function returning an Lvalue is intent on having it changed.

What I dislike about the bad forms is that a) it's not obvious that for is being used as a topicalizer rather than loop, unless you know the function in question, and b) if that function is for some reason ever changed to return additional elements, the "topicalizer" will turn into a loop and save the results from modifying the new return value element. Unless of course, you are using the variant which has scalar thrown in, but how likely is that?

In general I strive to write as self explanatory and easily readable code as possible, assuming the reader has a firm grasp of Perl. It is one of Perl's unique advantages (at least, the degree to which it's possible) that it lets you choose just how much red tape you want. In the terminology of Mark-Jason Dominus' second Program Repair Shop article: I try to minimize the amount of artificial code. At the same time I try to write the natural, essential code verbosely, straightforwardly, without obscure hacks and shortcuts. Well laid out data structures help this, another instance where I can get by with minimal red tape in Perl.

In that spirit, reason A is my big complaint. A topicalizing for should be clearly obvious as such.

Makeshifts last the longest.