develooper Front page | perl.perl5.porters | Postings from June 2015

Re: For 5.24: suggested incompatible changes

Thread Previous | Thread Next
June 27, 2015 11:38
Re: For 5.24: suggested incompatible changes
Message ID:
Reini Urban wrote:
>* @_ will be empty in a function with signature

This shouldn't be tied to signature syntax.  We discussed this back
when initially adding signatures.  We should certainly add features
for direct access to arguments, which signatures should use, and for
concomitant suppression of @_, but signatures should not be the only
way to get direct access, nor should signatures imply @_ suppression.

>* parse types in signatures

If only we had a type system in core.

>the illegalproto warning needs to go away then. an illegalproto is a
>signature, and there can only be a signature parser error then.

:prototype(wibble) is an illegal prototype.

>* no empty bare $ signature

It would be silly for signatures not to cover these cases.  This is the
wrong way to tackle your goal of making signature and short prototype
syntax non-clashing.  Bear in mind that the current signature syntax was
designed after we'd made the consensus decision that the clash would be
avoided by having the enablement of signature syntax disable the short
prototype syntax.  Clashes were therefore not a consideration in the
design process, and you can't retrofit a design goal that wasn't there.
Compare against the earlier "simple signatures", for which coexistence
with short prototype syntax *was* a consideration.

If you want to avoid the explicit syntactic switch of the signatures
feature flag, and not redesign signature syntax entirely, you can make
the syntax non-clashing by using square brackets instead of parens
to delimit signatures.  Or add some explicit prefix character such as
"+" to flag signatures.  I'd be happy with some version of this going
into core: it would be nice to reduce the massive confusion people have
between signatures and prototypes.

>* automatic prototypes from signatures

Shouldn't be done by default, because that would prevent people
using signatures on the great mass of public functions on CPAN that
are established as not having prototypes.  Generally, prototypes are
quite unpopular, so making them happen by default would go down badly.
(I think their unpopularity is unfair: it seems to stem from some backlash
at them not being signatures.)  Even where automatic prototype generation
is enabled, it would be good to have a way to prevent it for a single sub,
along the lines of :no_prototype.

>constant fold functions even without ()

It is indeed a priori silly that the () prototype is a prerequisite
for the built-in sub constant folding, but the constant folding
is semantically visible, so we can't go arbitrarily changing it.
An explicit :fold attribute might be a better way forward.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About