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

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
From:
Ricardo Signes
Date:
January 14, 2022 02:39
Subject:
Re: PSC #049 2022-01-07
Message ID:
67aa06f9-1719-4c73-b5ae-834d8d1f8a93@beta.fastmail.com
On Thu, Jan 13, 2022, at 2:06 PM, Karen Etheridge wrote:
> On Sun, Jan 9, 2022 at 4:38 AM Neil Bowers <neilb@neilb.org> wrote:
>> Our overriding desire is to get signatures "out there", but what's the right next step? There are at least 4 options: 
>>  1. Remove the experimental sticker off signatures and release that way in 5.36 (so you'd still have to `use feature` or `use v5.36`), but no other changes.
>>  2. As for 1, but also add a runtime warning if you touch @_ inside a signatured-sub.
>>  3. Like 2, but touching @_ is fatal.
>>  4. Inside signatured-subs @_ becomes non-special.
> 
> I am sympathetic to the concerns that #2/3/4 will have backcompat issues. I don't recall what the current situation is regarding cpan smokes, but this seems like a fairly easy change to make in a side branch and smoke against cpan to see what might break?  I use signatures a lot in new code, and in the cases where I touch @_ directly, I don't use a signature for that sub. Perhaps the majority of users are in the same situation and there won't be much fallout at all.

They would be easy to smoke if we had the patch, but we don't.

#2 and #3 are, so far as I understand, not really practical without slowing down quite a lot of code.

#4 is the one that has no runtime cost, but does introduce (I believe) a fair bit of lurking surprise for the unwary developer.  Also, we don't have a patch.

(You can see some of the early discussion of this whole topic, and how we might stop setting up @_ at all, in this 2016 p5p thread <http://markmail.org/message/iehupzyfuuuth3pg>.)

-- 
rjbs
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