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

Re: Urgent subroutine signatures problems

Thread Previous | Thread Next
Sawyer X
January 13, 2018 10:13
Re: Urgent subroutine signatures problems
Message ID:
Here is where I am at this point:

* We could not come up with a satisfying change to signatures to fully
disambiguate it from prototypes. This means we will result to only be
able to use signatures under "use feature" or "use VERSION". Not fun but
at least it's consistent and provides syntax people are happy with.

* The only way to support prototypes that affect signature compilation
(such as lvalue prototype) is by allowing prototypes on both sides. I do
not find the ability to put signatures before prototypes a compelling
enough reason for the work requires to support prototypes on both sides.
I also think it would create inconsistencies where some code would be
written with prototypes after and some with prototypes prior. Instead, I
think we will resolve to moving signatures again to be after prototypes.

Does anyone have any objections? Any suggestions? Anything we hadn't

On 12/13/2017 02: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.
> 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.
> Thank you,
> Sawyer.
> [1]
> [2]

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