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

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
From:
Darren Duncan
Date:
January 10, 2022 22:46
Subject:
Re: PSC #049 2022-01-07
Message ID:
34cd8e22-99f5-c729-9f60-394dbc050e88@darrenduncan.net
On 2022-01-10 3:44 a.m., Darren Duncan wrote:
> On 2022-01-09 4:37 a.m., Neil Bowers wrote:
>> The topic we've discussed a lot recently is what to do with @_ in 
>> signatured-subs: if your sub has a signature then you shouldn’t be touching 
>> @_. If we can remove support for @_ in signatured subs, that could give a 
>> performance boost, and also remove a class of potential bugs.
>>
>> 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 vote for something like number 3.
> <snip>

I partially retract what I said before.

To be honest, as a design feature I actually LIKE the "@_" of Perl, or 
specifically the concept of a single variable or thing that has all the routine 
arguments as a collection.  I even make this a fundamental feature of my own 
Muldis Data Language, where routines always conceptually have exactly 1 argument 
which is collection-typed, specifically it is a Tuple, I call it "args".

The main reason my previous answer picked number 3 was based on liking the 
argument that making "@_" non-special would be a big performance boost, and that 
was the main reason I supported it.

If it were possible to do in a performant way, my actual preference is for the 
behavior of signatures to fundamentally be a pretty syntactic shorthand for 
unpacking "@_" elements into lexicals, and @_ continues to also be available.

-- Darren Duncan

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