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

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

Thread Previous | Thread Next
Paul "LeoNerd" Evans
December 9, 2021 14:02
Re: "no snails"; or having signatured subs complain about @_
Message ID:
On Wed, 8 Dec 2021 21:18:30 +0000
Nicholas Clark <> wrote:

> On Tue, Dec 07, 2021 at 06:02:23PM +0000, Paul "LeoNerd" Evans wrote:
> > I think a lot of that isn't even necessary though. A variant of my
> > no-snails branch which I haven't yet committed or pushed, very
> > slightly relaxes the rules and allows a use of @_ as an rvalue in
> > scalar context, purely to allow the code to determine the argument
> > count.  
> > Potentially we could even still permit the use of @_ but only in
> > known-{scalar rvalue} contexts (such as the code above) allowing it
> > to continue to run unmodified from its current form. Already there
> > is lots of real code out in the wild (on CPAN and elsewhere) using
> > @_ in signatured subs in this way, and I think it would be nice not
> > to break them.  
> This was my view too, for this reason.
> It's the wrong design if we started from a clean sheet, but we aren't.
> Effectively we're saying that (for a while yet) we'll permit `scalar
> @_` as a strange special way to write builtin::argc (or something
> like that, if it ever comes to exist)
> But discourage it for new code. And at some point deprecate it.

Latest copy of the code on the branch (force-pushed) now permits
scalar(@_) as a means to query the argcount:

  $ ./perl -Ilib -Mfeature=signatures -E 'sub f(@args) { say "We have ", scalar(@_), " arguments" } f("a","b")'
  The signatures feature is experimental at -e line 1.
  We have 2 arguments

while still forbidding actual access as a real list/array, or elements
thereof. Also adds unit tests to this effect.

Paul "LeoNerd" Evans      |  |

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