Yes, but not everyone programs in a vacuum. Sooner or later they'll start using code which does have prototypes. Imagine, for example, that they start using Test::More. Those functions all have prototypes and using the leading ampersand is sure to bring them woe. Imagine, for example, typing "is" instead of "ok":

The prototype is now disabled so they don't get the compile-time failure telling them that the test function has been called incorrectly. If you're new to testing or that's buried in bunch of other tests, it can be quite difficult to figure out.

Sooner or later they'll start using code which does have prototypes.

Not if I can help it. Unless it's a specialized function that is trying to imitate a built-in, prototypes are forbidden in the code that I control.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Okay... so... uh... why the heck does Test::More use prototypes anyway?

-sauoq
"My two cents aren't worth a dime.";

To catch bad tests by being very specific about functions such as is() and like() taking two, optionally three, arguments.

Didn't write it. You'll have to ask the authors.

However, I don't mind it. More than once it's caught me writing a bad test and I can't recall any time I've been bitten by it.

Cheers,
Ovid

New address of my CGI Course.

OTOH, if they write something like:

    $a[0] = some_func(2, 3);
    $a[1] = 17;   # Expected outcome.
    &is(@a);
[download]

their code runs fine, and it isn't getting generating errors about a mismatch of the number of arguments. I'd say that '&' disables mysterious side-effects.
Perl --((8:>*

#!/usr/bin/perl
use strict;
use warnings;

yes_ampersand("yes\n");
no_ampersand("no\n");

sub foo {
    print $_[0];
}

sub yes_ampersand {
    print $_[0];
    &foo;   
}

sub no_ampersand {
    print $_[0];
    foo;    
}
[download]

yes
yes
no
Use of uninitialized value in print at ampersands.plx line 9.
[download]

I made it clear in my original node that I'm not referring to a bare &foo, but rather &foo(...).

---

Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

I should have elaborated. Here's "what's so bad about &function(...)":

The ampersand has a very subtle quirk which arises when it is used without parentheses, as illustrated in my previous post.

The directive "don't use the ampersand" is easy to understand and follow. If you get "bareword" errors, they generally cause catastrophic failure and are thus straightforward to troubleshoot, even for beginners.

The use of parentheses to group arguments to a subroutine is not enforced by Perl. Usage is all over the place.

The directive "go ahead use the ampersand, but only with parentheses" is more difficult for a beginner to adhere to, because in the vast majority of cases there is no penalty for omitting the parentheses. When they do finally hit a problem because they forgot the parens, it's not going to be a nice easy bareword crash -- it's going to be a silent killer.

IMO, it's not reasonable to argue that there's no problem with &function(...) while punting on &function, and since there's a problem with &function, there's a problem with &function(...).

Feel free to disagree. :)

--
Marvin Humphrey
Rectangular Research ― http://www.rectangular.com