Front page | perl.perl5.porters |
Postings from February 2015
l.mai@web.de wrote:
>The syntax 'sub foo :attributes ($signature) { ... }' is awful. It
>should be 'sub foo($signature) :attributes { ... }'. (This might be a
>candidate for bug #121481.)
I do not approve of this change. It gives the misleading impression
that the signature is metadata that could reasonably be examined by
distant code. I believe the request for this change comes largely from
people misunderstanding signatures in precisely that manner.
>Why? Because syntactically the signature replaces what used to be the
>prototype, and that comes before attributes.
It only `replaces' prototype syntax in the sense that there is a syntactic
clash between them that we have resolved by having the signature-syntax
feature flag also disable prototype syntax. It is not a replacement in
the sense of any semantic substitutability: signatures and prototypes
address different aspects of subroutines, neither can do what the other
does, and neither makes the other irrelevant. It is perfectly sensible
for a subroutine to have both.
Nor was it a priori necessary that enabling signature syntax would disable
the short prototype syntax; recall the "simple signatures" that I did
before the present signatures, which allowed "sub ($$) ($foo, $bar) { }".
It is not at all necessary that syntactically clashing alternatives fill
exactly the same syntactic slot. A lot of Peter Martini's signature
patches suffered terribly from this preconceived notion that signatures
had to occupy precisely the syntactic slot of prototypes.
The perpetuation of this misunderstanding of signatures as a funny kind
of prototype is rather making me regret implementing signature syntax.
I'm still satisfied at having forestalled some really terrible patches
that were in danger of being accepted, but perhaps I should have demanded
that we find non-clashing syntax, or some way of resolving the clash
that doesn't disable the short prototype syntax.
>It's also what perl itself does in C. :-)
>
> OP* Perl_newDEFSVOP(pTHX) __attribute__((warn_unused_result));
Utterly irrelevant, because of fundamental differences between the
two languages. C's parenthesised formal parameter list, which in a
declaration is actually called the "prototype", *is* metadata that must
be declared before call sites can be compiled, so has just about the same
status as gcc's attributes. Comparing to Perl, the C prototype is more
akin to a Perl prototype than to a Perl signature. Though in a function
definition (as opposed to declaration) the formal parameter list fulfills
both roles, which would be akin to a Perl signature implying a prototype.
If we had implemented such an implication, then it *would* have been
reasonable to allow a sub declaration with signature, just in order to
get the implied prototype. The general unpopularity of prototypes in
Perl ruled out us implementing that kind of implication.
Ultimately, gcc's placement of the attribute clause in the syntax is an
arbitrary choice.
-zefram
Thread Previous
|
Thread Next