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

Re: De-experimentalising "signatures"

Thread Previous | Thread Next
Darren Duncan
March 27, 2021 05:28
Re: De-experimentalising "signatures"
Message ID:
On 2021-03-22 9:12 a.m., Leon Timmermans wrote:
> On Mon, Feb 15, 2021 at 1:35 PM Dave Mitchell <> wrote:
>> I have pushed for keeping them experimental because I want to change
>> things so that @_ isn't populated in signatured subs (or more precisely @_
>> isn't localised and is still the @_ of the caller), and that breaks
>> backwards compatibility.
> That does sound reasonable. I'm not sure why we haven't done so
> already; that would have prevented this situation.
>> It's also dependent on other new signature
>> features being added which do away with needing access to @_.
> As long as it still exists when no signature is present, I think that
> doesn't need to be a problem?

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.

So on one hand, enabling signatures makes the first example a shorthand for the 

   sub myfunc ($x,$y,$z)

   sub myfunc
     my ($x,$y,$z) = @_;

And you can still examine or test @_ in any way that you could before.

In addition, having a signature on a routine means that Perl will raise an error 
if its not called correctly.  Because the signature serves as a predicate or 
pattern of sorts that says the argument set must match that pattern.

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.

-- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About