Not sure I'd bracket 'works as expected' and Perl together :-)
For completeness, it's being parsed as:
print STDERR("+++STDERR: '", ....) ; -- predeclared sub STDERR without a prototype.
print STDERR() "+++STDERR: '", .... ; -- predeclared sub STDERR ()
where the second is treated as a broken expression involving the return value of STDERR().
This behaviour is consistent with the general handling of subroutines referenced by a bareword.
Where a FILEHANDLE may appear the parser has to jump through hoops to allow print $FH ...., which it parses as a FILEHANDLE and leaves as a run-time problem. With an ordinary print FH .... the parser also leaves checking that FH actually refers to something to run-time.
Having predeclared sub FH () { *FH } ; I can see that the parser is in a bit of a bind when it sees print FH "Hi!";. The prototype says that FH("Hi!") is not the correct interpretation. But it does know that FH is a sub..., even though, on the face of it, it looks just like a filehandle !
I imagine that generalising print FH .... even further, so that the FH could be an expression that returned a filehandle object, would be a nightmare -- leaving broken code to be found at run-time. However, the special case of a predeclared subroutine with a () prototype might be a small step ?
The other thing that is special about filehandles is that there is no way to declare them. Suppose one could declare our FH : filehandle ; (say). Now: (a) strict could throw out print SPELING_ERROR ...; and (b) use of FH in an expression could return *FH{IO} implicitly, so some_sub(FH, ....) or $object->{handle} = FH would work just fine ! Of course, STDERR et al could then be predeclared with a 'filehandle' attribute :-)
|