develooper Front page | perl.perl5.porters | Postings from December 2017

Re: Urgent subroutine signatures problems

Thread Previous | Thread Next
Leon Timmermans
December 24, 2017 22:24
Re: Urgent subroutine signatures problems
Message ID:
On Wed, Dec 13, 2017 at 2:46 PM, Sawyer X <> wrote:

> I want to surface two critical subroutine signature issues, one
> previously raised by Zefram. These are urgent since they are breaking
> issues. We should discuss them and resolve them quickly.
> It is better to break more things now than several times over time since
> each one resets the clock on the stability of signatures. We might as
> well resolve all breaking changes together.
> 1. Lvalue subroutines are now broken as a result of the placement of
> subroutine signatures (RT #132141)[1]:
> The reason for this is simple: Lvalue subroutines use the :lvalue
> subroutine attribute and subroutine attributes now come after the
> signature. Considering subroutine signatures can contain arbitrary code
> and :lvalue changes compilation, this, in effect, means that those
> features are now mutually exclusive. You cannot use :lvalue to affect
> compilation of any code in subroutine signatures.
> One way to fix this would be to move subroutine signatures following
> subroutine attributes. Another fix would be to allow them both before
> *and* after, putting the responsibility on the user of using :lvalue
> (and such attributes that alter the subroutine in similar ways) before
> defining the subroutine signature. These solutions can be pretty
> fragile. Another option is to recognize which attributes should appear
> only before signatures and trigger an error if they appear after the
> signatures instead.

Last time we had such a discussion (and switched the order around) I
remember it having impact on Catalyst users (as they're pretty much the
only heavy users of attributes in perl). Reaching out to them specifically
would seem like a good idea to me.

> 2. Having signatures available without explicitly enabling them
> While we could "use feature" subroutine signatures, it would be even
> better if they were simply available without using a pragma. However,
> their syntax clashes with prototypes, meaning we can't have them enabled
> by default without breaking backward compatibility. We are forced to
> hide signatures behind a pragma.
> Short-form prototype syntax is a stable feature that works by default on
> all versions since 5.002. The :prototype attribute didn't exist until
> 5.20, so backward-compatible code doesn't even have a choice about how
> to use prototypes. It would be wrong to break this.
> If the syntax didn't clash, then we could have signatures enabled by
> default and not lose backward compatibility. Just as an example of a
> clear distinction between signatures and prototypes, Zefram suggested
> using square brackets for signatures[2]. This change would allow having
> subroutine signatures enabled without any pragma, which is quite appealing.
> I think these issues are critical enough at this point to invite the
> community at large to provide input and feedback on this. I will be
> publishing a blog post on this topic, encouraging people to join the
> discussion on it.

I think the current solution is the obvious one. Needing a pragma is
unfortunate, but using non-intuitive syntax is much worse.


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