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

Re: De-experimentalising "signatures"

Thread Previous | Thread Next
B. Estrade
March 27, 2021 08:34
Re: De-experimentalising "signatures"
Message ID:

On 3/27/21 12:28 AM, Darren Duncan wrote:
> 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.

I agree with the above statement; personally, I think the number of 
experimentals should be minimized at any given time. "say" is still 
experimental, or at least requires 5.10. Why it's not just enabled, I 
have no idea. Anyway;

In an earlier email I suggested outlining the cases in which @_ should 
be accessible, and could actually provide some strictness. The main 
sticking point I've gathered is signatures in the context of the caller 
using the dereference form of a method call on a blessed reference 
(i.e., an instantiated Perl "object"), given all it does is prepend the 
__PACKAGE__ name as a scalar value to the parameter list.

Since I already went through it, here's the link with my own set of 
examples for each case I identified:

I am sure I didn't account for something or this doesn't exactly answer 
the question for a path forward. But I do believe identifying all of the 
cases, and if they can be all shown to be unambiguous enough as to not 
break existing subroutine definitions in CPAN, then that might be enough 
to identify what provisions need to be made to certify signatures once 
and for all - or at least provide it like "say" with a version pin.

> So on one hand, enabling signatures makes the first example a shorthand 
> for the second:
>    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.

This is also my preference. Anyway, hth.


> -- Darren Duncan

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