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