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

Re: Urgent subroutine signatures problems

Thread Previous | Thread Next
From:
Sawyer X
Date:
January 13, 2018 10:23
Subject:
Re: Urgent subroutine signatures problems
Message ID:
ea8fdbd6-1fbe-ba72-1817-406deb8e0fd0@gmail.com
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/247237

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