Front page | perl.perl5.porters |
Postings from January 2018
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