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 11:45
Subject:
Re: PSC #049 2022-01-07
Message ID:
63125c3b-d7cd-b7dd-6d50-b6983008a98f@darrenduncan.net
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.
When a file says "use v5.36" or a higher version, it causes signatures to be
available non-experimentally AND it causes @_ to not be declared within the
scope of any sub using a signature, wherein any references to @_ will fail AT
PARSE/COMPILE time.
Since "use v5.36" already enables strict, the failure with @_ can reported as a
reference to an undeclared variable like other violations of strict do.
Or at the very least, what I advocate for is that within the scope of any sub
having a signature, there does not exist an @_ with any kind of special
behavior, and the performance optimization exists.
That means any kind of explicit message to the user about @_, whether a warning
or a fatal error, it happens at parse/compile time, and not at runtime, of the
code, because runtime requires the special logic that slows things down.
I think making this fatal is best, so people don't gain bugs from @_ not having
the arguments because they just happened to miss new warnings.
This stricter behaviour should not break any existing code because it only
occurs when they explicitly "use v5.36" or they otherwise use-signatures without
experimental, meaning it is a change they explicitly opted into in the same file
as the affected sub.
-- Darren Duncan
Thread Previous
|
Thread Next