I think that you've overplayed the case. Using a do block instead of an anonymous block makes it look more complicated than it is.

Even wrapping a local var in a bare block is rarely necessary. Most code is nested at some level in a if or while or other loop block or subroutine body.

On the rare occasions that it is at the top level of a program or module, if you really want it to be garbage collected, undef is better (in that it will actually achieve something) anyway.

Even the use of a constant is a emphasising the rare case. Mostly data is read in from external sources and is in a variable already, so:

while( my $var = <$fh> ) {
    mutate( $var );
    use( $var );
}
[download]

is hardly onerous, but even that can be avoided. Thanks to perl's context sensitivity, you can have the best of both worlds. For the simple case, subroutines behave as passthru pass-by-value, but when the need arises to minimise memory allocation and copying, using it ina void context does the right thing:

#! perl -slw
use strict;

sub mutates {
    my $ref = defined wantarray ? \shift : \$_[ 0 ];
    $$ref =~ s[(?<=\b[^ ])([^ ]+)(?=[^ ]\b)][scalar reverse $1]ge;
    return $$ref if defined wantarray;
    return;
}

sub doSomething {
    print shift;
}

doSomething( mutates( 'antidisestablishmentarismania' ) );

my $var = 'The quick brown fox jumps over the lazy dog';
mutates( $var );
doSomething( $var );

__END__
c:\test>junk
ainamsiratnemhsilbatsesiditna
The qciuk bworn fox jpmus oevr the lzay dog
[download]

Thanks to perl's context sensitivity, you can have the best of both worlds. For the simple case, subroutines behave as passthru pass-by-value, but when the need arises to minimise memory allocation and copying, using it ina void context does the right thing

Now that's surely tempting, but could lead to rather odd situations:

sub do_stuff {
    ...
    do_other_stuff($variable);
    # remove that debugging statement, and do_other_stuff
    # will behave very differently if do_stuff is not
    # called in void context
    print "still here\n";
}
[download]

Admittedly that's a fairly artificial situation and won't show up in real code very often, but if it does it's very nasty to debug.

Designing interfaces around performance optimizations and memory management oddities just doesn't seem right to me.

If that function is called in a non-void context, it is returning the result of the "debug statement", which seems more than a little artificial.

If the function is ever called in a non-void context, it will be because it returns something useful. If the return statement (or the fall-off-the-end expression) is omitted, then the function isn't going to work the way it is intended anyway, so any other error is academic. Just another justifiction I'm afraid.

Plenty of languages use pass-by-reference, and thousands of programmers and millions of programs use it every day without dire consequences.

Designing interfaces around performance optimizations and memory management oddities just doesn't seem right to me.

You seem to be saying: Oh, I mustn't use this language feature, because that would make my code more efficient and that would be an optimisation and it might be premature!

Why does Text::CSV_XS exist? Or the XS version of List::Util? Or ...

It's changing your transatlantic flight path to take full advantage of (or avoid) the gulf stream. It's shutting off the fuel supply to the injectors when the engine is on overrun. Removing your roof rack when you aren't using it.

Perl is a context sensitive language, it is a uniquie and powerful defining feature. Perl programmers need to be aware of it, understand it and use it. Pretending it doesn't exists, or running scared of it you might as well use VB.

It drives me nuts. I use Perl, because I like the language. But there are people around here won't use map or grep; or statement modifiers; or unless or until. They eshew aliasing; context sensitivity; autovivification; the implicit variables: it and these. They want everything OO; will jump through hoops creating singleton classes, "to avoid globals" and end up with nothing more than lexically-scoped globals (eg. our). Use ReadOnly variables as constants instead of constants.

Why bother using Perl?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Are

chomp( my $var = <$fh> );
[download]

and

chomp( my $dst = $src );
[download]

really more tedious and uglier than

my $var = chomp( scalar ( <$fh> ) );
[download]

and

my $dst = chomp( $src );
[download]

They are. funcall(<variable assignment>) is a useful idiom in programming languages where assigment returns (an alias to) the value of the variable, but it is counter-intuitive at first. Even though I have been programming in Perl and curly brace block syntax languages for years, I still find it hard to read -- mostly because when you normally delimit my with braces, you create a new lexical scope. That's what chomp(my $foo = bar) still seems to be, even if I know better and use the idiom frequently.

Not only that, but it is not obvious that the value of $var in chomp(my $var = <$fh>) is being modified at all! After all, assignment, if used in other contexts, returns the value, not a reference to it. my $foo = $bar = 1 doesn't create a reference in $foo, but sets the value of both variables to 1. In fact, I am not sure what the underlying mechanism is. Does it work because assignment returns an alias similar to aliased values in @_ in function calls?

Side-effect free chomp has no similar conceptual problems.

--
say "Just Another Perl Hacker";