Why are Perl 5's function prototypes bad?

In another Stack Overflow question Leon Timmermans asserted:

I would advice you not to use prototypes. They have their uses, but not for most cases and definitely not in this one.

Why might this be true (or otherwise)? I almost always supply prototypes for my Perl functions, and I've never before seen anyone else say anything bad about using them.

Prototypes aren't bad if used correctly. The difficulty is that Perl's prototypes don't work the way people often expect them to. People with a background in other programming languages tend to expect prototypes to provide a mechanism for checking that function calls are correct: that is, that they have the right number and type of arguments. Perl's prototypes are not well-suited for this task. It's the misuse that's bad. Perl's prototypes have a singular and very different purpose:

Prototypes allow you to define functions that behave like built-in functions.

• Parentheses are optional.
• Context is imposed on the arguments.

For example, you could define a function like this:

sub mypush(\@@) { ... }

and call it as

mypush @array, 1, 2, 3;

without needing to write the \ to take a reference to the array.

In a nutshell, prototypes let you create your own syntactic sugar. For example the Moose framework uses them to emulate a more typical OO syntax.

This is very useful but prototypes are very limited:

• They have to be visible at compile-time.
• They can be bypassed.
• Propagating context to arguments can cause unexpected behavior.
• They can make it difficult to call functions using anything other than the strictly prescribed form.

See Prototypes in perlsub for all the gory details.

The problem is that Perl's function prototypes don't do what people think they do. Their purpose is to allow you to write functions that will be parsed like Perl's built-in functions.

First of all, method calls completely ignore prototypes. If you're doing OO programming, it doesn't matter what prototype your methods have. (So they shouldn't have any prototype.)

Second, prototypes aren't strictly enforced. If you call a subroutine with &function(...), the prototype is ignored. So they don't really provide any type safety.

Third, they're spooky action-at-a-distance. (Especially the $ prototype, which causes the corresponding parameter to be evaluated in scalar context, instead of the default list context.)

In particular, they make it hard to pass parameters from arrays. For example:

my @array = qw(a b c);

foo(@array);
foo(@array[0..1]);
foo($array[0], $array[1], $array[2]);

sub foo ($;$$) { print "@_\n" }

foo(@array);
foo(@array[0..1]);
foo($array[0], $array[1], $array[2]);

prints:

a b c
a b
a b c
3
b
a b c

along with 3 warnings about main::foo() called too early to check prototype (if warnings are enabled). The problem is that an array (or array slice) evaluated in scalar context returns the length of the array.

If you need to write a function that acts like a built-in, use a prototype. Otherwise, don't use prototypes.

Note: Perl 6 will have completely revamped and very useful prototypes. This answer applies only to Perl 5.

I agree with the above two posters. In general, using $ should be avoided. Prototypes are only useful when using block arguments (&), globs (*), or reference prototypes (\@, \$, \%, \*)