Hmmm... it's just been one of those things that I've taken for granted all these years, and for the life of me, I couldn't remember where I learned it. (might've been from someone, from a book, or something that I inferred). Anyway, you made me wonder if I'm potentially wrong, so I did a bit of digging on the subject. (I've found out before that things that I've thought I've known for years were actually incorrect.)

It seems that &bareword is handled as special, but not for the reason I had thought. (and my C's rusty enough, that I don't know if I'm up for going through the perl source to see exactly how that syntax is treated differently.

In looking through the Perl 4 documentation, there's a hint that &bareword is just a little bit different:

Subroutines may be called recursively. If a subroutine is called using the & form, the argument list is optional. If omitted, no @_ array is set up for the subroutine; the @_ array at the time of the call is visible to subroutine instead.

        do foo(1,2,3);          # pass three arguments
        &foo(1,2,3);            # the same

        do foo();               # pass a null list
        &foo();                 # the same
        &foo;                   # pass no arguments--more efficient
[download]

In a current copy of perlsub, we find a brief mention of & being special:

    NAME(LIST);    # & is optional with parentheses.
    NAME LIST;     # Parentheses optional if predeclared/imported.
    &NAME(LIST);   # Circumvent prototypes.
    &NAME;         # Makes current @_ visible to called subroutine
[download]

and further down there's a little more detail:

A subroutine may be called using an explicit & prefix. The & is optional in modern Perl, as are parentheses if the subroutine has been predeclared. The & is not optional when just naming the subroutine, such as when it's used as an argument to defined() or undef(). Nor is it optional when you want to do an indirect subroutine call with a subroutine name or reference using the &$subref() or &{$subref}() constructs, although the $subref->() notation solves that problem. See perlref for more about all that.

Subroutines may be called recursively. If a subroutine is called using the & form, the argument list is optional, and if omitted, no @_ array is set up for the subroutine: the @_ array at the time of the call is visible to subroutine instead. This is an efficiency mechanism that new users may wish to avoid.

</code> &foo(1,2,3); # pass three arguments foo(1,2,3); # the same foo(); # pass a null list &foo(); # the same &foo; # foo() get current args, like foo(@_) !! foo; # like foo() IFF sub foo predeclared, else "foo"

</code>

Not only does the & form make the argument list optional, it also disables any prototype checking on arguments you do provide. This is partly for historical reasons, and partly for having a convenient way to cheat if you know what you're doing. See Prototypes below.

Looking through the current documentation, we find that package::function() syntax is a little bit special, too:

o unambiguously refer to the built-in form, precede the built-in name with the special package qualifier CORE:: . For example, saying CORE::open() always refers to the built-in open() , even if the current package has imported some other subroutine called &open() from elsewhere. Even though it looks like a regular function call, it isn't: you can't take a reference to it, such as the incorrect \&CORE::open might appear to produce.

So, it looks like yes, they're both special, but the reason I gave wasn't quite accurate. As well as I can get from all of this, &bareword forces backwards compatability to perl 3. merlyn stated that in the days before I was using Perl, ampersands were required.

There's also a note in Exporter about problems with using barewords for constants when they're handled through AUTOLOAD. I'm not sure if this extra checking might be significant. (I'm going to need to do some testing, but I've got to run to work now).