On Tue, 7 Dec 2021 09:59:28 +0000 Dave Mitchell <davem@iabyn.com> 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 https://github.com/leonerd/perl5/commits/no-snails (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 > http://nntp.perl.org/group/perl.perl5.porters/256677 > > and more specifically in the subthreads: > > @_ Suppression > http://nntp.perl.org/group/perl.perl5.porters/256681 > > Query Parameters > http://nntp.perl.org/group/perl.perl5.porters/256680 > > 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 https://github.com/Perl/perl5/commit/70657aee92d84a1cd5a50bd81dfab71001372aad > 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 leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next