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 7, 2021 17:38
Re: "no snails"; or having signatured subs complain about @_
Message ID:
On Tue, 7 Dec 2021 09:59:28 +0000
Dave Mitchell <> wrote:

> TL;DR: we need to agree what minimal changes we need for 5.36.0 to
> allow it to move out of experimental mode (not necessarily moving out
> in 5.36.0, but setting the foundations for moving it out in 2
> releases time).

I've been working on something similar to this. Branch is in

(though I'm regularly rebasing + force-pushing so I won't link to
individual commits as they may move)

> My original proposals can be found in the thread
>     Jumbo Signatures extensions discussion
> and more specifically in the subthreads:
>     @_ Suppression
>     Query Parameters
> But it boils down to:
> 1) subs compiled within the scope of 'use signatures' don't get @_
> populated: @ is still the @_ of the caller. There is no separate
> pragma or other switch to allow this to be dis/enabled on a per-sub
> basis: if it's a signature sub, it doesn't get @_, full stop.
> Otherwise we'd have to have two code paths, two sets of tests etc for
> everything.

So far I have added a flag for this:

  0356f47c3b Define a CvSIGNATURE flag

  58603027bc Set the CvSIGNATURE flag on signatured subs

which allows pp_entersub to distinguish this situation.

> 2) Within the lexical scope of a signature sub (but not in the scope
> of e.g. nested signature-less anon subs etc), use of @_ and $_[X] is a
> compile-time warning. This should catch most coder errors associated
> with converting existing subs to use signatures.

Currently my code makes any access of @_ into a runtime error, purely
because that was somewhat easier to write than trying to make it
compiletime. It's enough to give a test of what things we have lurking
in core itself that would need updating, though yes a real release
wants it to be compiletime.

Mine is currently done with a new kind of magic applied to
GvAV(PL_defgv) within a signatured sub, that complains about any kind
of access on it.

  809465cb35 Define a new type of variable magic, which prints an error
             that access to a named variable is entirely forbidden

  5eb1f7b999 Extend av_fetch() to check for PERL_MAGIC_forbidden on AVs

  fc21e9e91e Apply PERL_MAGIC_forbid to @_ when running a signatured sub


> 4) In terms of implementation, the only logic that should go in
> pp_entersub() is checking a flag on the CV to see if it's a signatured
> sub. If so, it uses a pre-existing code path - the '&foo;' call
> mechanism. All the other logic should go in the sub itself -
> initially just as extra code in the OP_ARG* ops; later additions will
> add extra ops, and sometime after the sig implementation is complete,
> the optimiser will convert a suitable series of OP_ARG* ops into a
> single OP_SIGNATURE op which processes all args.

I altered the OP_ARG* code to pull the arguments out of the AV in pad
index 0:

  8f767a2202 Get the pp_arg* funcs to look in PAD_SVl(0) instead of
             GvAV(PL_defgv) for the args AV

Which seemed sufficient to at least allow them to continue to work,
while access to @_ was forbidden. That won't work for the longterm,
because in the longterm we (probably?) won't be putting the argument
values into the pad slot 0 AV either. But that's more of an internal
optimisation and shouldn't be user-visible so I wanted to focus on the
"ban @_" part first.

Overall, besides the first two commits that created CvSIGNATURE, plus
various fixes to tests/other files that were still using snail inside
signatured subs, I'm not particularly fond of the rest of what I made.
It was just a test to get this far and fix things like mktables. See

> If agreement is reached, I'm likely to have enough
> enthusiasm to do the implementation work.

Yes; for the overall direction it would be good to find a good next set
of steps, and see about implementing those. In the meantime, I'm happy
to continue to use my current hack as a spyglass to find other code in
the core dist that would suffer "collateral damage" from a no-snails
change. We can (and should) just fix those up anyway, regardless of any
actual behavioural change to signatures for real.

I guess a "next step" would be to more precisely pin down what
behaviour we expect to see out of @_ within signatured subs, perhaps
by writing some more test cases in the style of t/op/signature.t so we
can agree on how it should behave.

Paul "LeoNerd" Evans      |  |

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