develooper Front page | perl.perl5.porters | Postings from January 2018

Re: Urgent subroutine signatures problems

Thread Previous | Thread Next
From:
Sawyer X
Date:
January 1, 2018 09:25
Subject:
Re: Urgent subroutine signatures problems
Message ID:
41faa7d6-2d21-e513-17d9-ea57707fd6d0@gmail.com


On 12/25/2017 12:24 AM, Leon Timmermans wrote:
> On Wed, Dec 13, 2017 at 2:46 PM, Sawyer X <xsawyerx@gmail.com
> <mailto:xsawyerx@gmail.com>> 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.

I reached out to John about this. I'm leaning towards moving the
signatures after attributes at the moment.

>  
>
>     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.

I'm reaching the same conclusion too.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About