Front page | perl.perl5.porters |
Postings from December 2017
On Wed, Dec 13, 2017 at 2:46 PM, Sawyer X <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. > 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. LeonThread Previous | Thread Next