1. using &subname; without braces does not do what you probably think it does. It passes the current value of @_ to the called sub - and subname() update: or subname; does not.

2. when you're passing arguments, most of the time the you are either using braces and/or the subroutine has already been defined, and in both cases the & is not needed. Also strict will warn you if it gets confused in this case. Basically, not using "&" will save you typing.

The only times I use &subname is when a) I want to create a reference to a named subroutine (which is fairly rare), or b) I want to do goto &subname; (which is an even more rare, but does have its uses in that it's the only way to "fake tailrecursion" in perl - see goto)

... or b) I want to do goto &subname; (which is an even more rare, but does have its uses in that it's the only way to "fake tailrecursion" in perl - see goto)

Actually thats not correct, it is neither the only nor the best way to "fake tailrecursion". The best way to fake tail recursion is to use a while or for loop. The overhead of goto &sub is actually quite expensive compared to a proper loop.

Tail recursion optimisation is only really important in languages which lack looping constructs. Yet the meme that "tail recursion optimisation is cool and useful" somehow manages to leak out of languages that really do need it into languages that don't really need it. And Perl has a rich set of looping constructs making tail recursion and its optimisation much less important than people think. This is actually one of the reasons that perl doesnt bother with this optimisation. (Its not the only reason tho given Perls dynamic nature.)

Remember that all tail recursion optimisation does is quietly convert your tail recursive call into a loop.

---
$world=~s/war/peace/g

Well, yes.

But, it can be useful to have the called subroutine determine the next call instead of moving the determining code to the calling routine. And doing that "naively" will lead you running out of call stack if you have enough nested calls.

I've used the goto &subroutine; construct to get out of that situation.

I acknowledge that this isn't strictly tail recursion.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

&snafu, as you have it, without parentheses, is actually even more magical: It passes the current @_ toshares the current @_ with the function called. Which you rarely, if ever, want.

(Updated: Yeah, that's better. lodin++.)

The &snafu(@args), &snafu(), and &snafu forms are useful in very rare situations, and the & is a nice flag for just those instances: When I see it in my code, I know I'm doing something strange. Which is also useful.

So yeah, not just aesthetics. Compelling enough? You make the call. But my recommendation for &-form calls is as for prototypes:

Don't use it if you don't mean it!

It passes the current @_ to the function called.

This is probably just a matter of wording, but I'd say it's sharing @_. &foo and foo(@_) are not equivalent. An example:

sub foo1 { &bar;    print "@_\n"; }
sub foo2 { bar(@_); print "@_\n"; }

sub bar { shift }

foo1(1, 2, 3);
foo2(1, 2, 3);

__END__
2 3
1 2 3
[download]

lodin

Would you use system "rm -rf" or del \*.* in your code if you didn't know what they did?

The fact that you had to ask this question tells me that you should not be using &func.

See also (tye)Re: A question of style, which tries to bring together most of the points on this issue.