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

Re: "no snails"; or having signatured subs complain about @_

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
December 4, 2021 20:56
Subject:
Re: "no snails"; or having signatured subs complain about @_
Message ID:
YavV46gGa3wkhcIS@etla.org
On Fri, Dec 03, 2021 at 08:41:14PM +0000, Paul "LeoNerd" Evans wrote:
> On Fri, 3 Dec 2021 20:58:53 +0100
> Juerd Waalboer <juerd@tnx.nl> wrote:
> 
> > However, it seems to me that there should be a better, and officially
> > supported, way to do this.
> 
> Yeah I was probably going to make something like `builtin::argc`, to
> give you a way to enquire:
> 
>      use builtin 'argc';
> 
>      sub bar($self, $new = "blah") {
>          $self->{bar} = $new if argc == 2;
>          $self->{bar};
>      }

I *think* that if an implementation of builtin::argc exists, then it should
be possible to compile "@_ in scalar context" to the same op as
`builtin::argc`, and `$#_` to `(builtin::argc - 1)`

either in the parser directly, or in the peephole optimiser

(recognising exactly pp_gv on *_ followed by rv2av in scalar context,
or this with pp_av2arylen. But I really mean only the literal use of @_
in compile-time known scalar context, or literal $#_. Not "take a reference
to @_ and then happen to do this to the reference" on anything semantically
equivalent)

ie what ends up in the optree is entirely implemented with the runtime for
builtin::argc, and doesn't point to, reference or use @_ at all.

I don't think that doing this complicates the ops executed, but doing it
means that (more) existing code using signatures will continue to work
unchanged, and can be written in a way that works before and after v5.36.0
without any new dependencies.

Nicholas Clark

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