develooper Front page | perl.perl5.porters | Postings from March 2021

Re: De-experimentalising "signatures"

Thread Previous | Thread Next
From:
Darren Duncan
Date:
March 27, 2021 20:42
Subject:
Re: De-experimentalising "signatures"
Message ID:
45925a5a-1b9a-8889-3258-4bb443026fec@darrenduncan.net
On 2021-03-27 5:39 a.m., Paul "LeoNerd" Evans wrote:
> On Fri, 26 Mar 2021 22:28:30 -0700 Darren Duncan wrote:
> 
>> I would propose and expect that @_ should continue to behave the same
>> as it always did, and be available in every subroutine, and that
>> signatures just provides an overlay plus constraint check.
> ...
>> The key thing is that I consider access to a single value
>> representing the entire collection of actual arguments to be an
>> important fundamental feature that should never go away.
> 
> I don't think anyone is suggesting to get rid of @_ because they don't
> "like" it, or it's messy or confuses newbies or anything.
> 
> The primary motivation to get rid of @_ is that it is slow. It is a
> large performance drain on the overhead of the ENTERSUB op, which is
> involved in every single function call that Perl ever makes. If we were
> able to skip that part for the majority of subs which don't need it
> (because they'd be written with signatures), then the entire program
> runs faster.
> 
> Performance is a feature.

Okay, if its about performance, then I support the @_ removal on subs with 
signatures.

It can be fairly straightforward then, each sub is either of 2 kinds, one with 
signatures and without @_, or one without signatures and with @_.

So those that want to write atypical subs that need to access @_ can just 
implement those specific subs without signatures.

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