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 ClarkThread Previous | Thread Next