Re: 36-uniq.patch

[Russ Allbery]

Akim Demaille <address@hidden> writes:

> I am not aware of the problems.  I know they forbid things, but then
> using & again fixes the issue (i.e., I'm not aware of problems which
> require removing the prototype, adjusting the call is enough).

The major issue is this one, from perlsub:

   It's probably best to prototype new functions, not retrofit prototyping
   into older ones.  That's because you must be especially careful about
   silent impositions of differing list versus scalar contexts.  For
   example, if you decide that a function should take just one parameter,
   like this:

       sub func ($) {
           my $n = shift;
           print "you gave me $n\n";
       }

   and someone has been calling it with an array or expression returning a
   list:

       func(@foo);
       func( split /:/ );

   Then you've just supplied an automatic "scalar" in front of their
   argument, which can be more than a bit surprising.  The old "@foo" which
   used to hold one thing doesn't get passed in.  Instead, "func()" now gets
   passed in a "1"; that is, the number of elements in "@foo".  And the
   "split" gets called in scalar context so it starts scribbling on your
   "@_" parameter list.  Ouch!

The main purpose of prototypes is to allow you to reproduce the semantics
of build-in functions; the \@ and \% prototypes are particularly useful.
Simple scalar prototypes I don't find particularly useful; I find the
imposition of scalar context on the arguments to be odd action-at-a-
distance that's often quite surprising and strange.  For example, the
sudden complete failure of "func(@args)" to do anything remotely like what
one would expect, even if func takes three arguments and there are three
members of the @args array, strikes me as undesireable behavior.

I think in general the more you know Perl the more prototypes cause odd
and hard-to-explain things to happen.  If you're writing very, very C-like
Perl, they're less of an issue because you don't even try to use some of
the more powerful and idiomatic Perl constructs that can be adversely
affected by unexpected scalar context imposition.  For example, the C-like
Perl programmer is more likely to write func($args[0], $args[1], $args[2])
because they don't know how array flatening in parameter lists works and
they don't expect func(@args) to just do the right thing (which it does,
in the absence of prototypes).

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>