Front page | perl.perl5.porters |
Postings from January 2018
Err.. I meant subroutine attributes when referring to the ":lvalue". Sorry. On 01/13/2018 11:13 AM, Sawyer X wrote: > 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 > considered? > > 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] https://rt.perl.org/Ticket/Display.html?id=132141 >> [2] http://nntp.perl.org/group/perl.perl5.porters/247237Thread Previous | Thread Next