develooper Front page | perl.perl5.porters | Postings from January 2022

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
Ricardo Signes
January 9, 2022 16:34
Re: PSC #049 2022-01-07
Message ID:
On Sun, Jan 9, 2022, at 7:37 AM, Neil Bowers wrote:
>  Our overriding desire is to get signatures "out there", but what's the right next step? There are at least 4 options:
>  1. Remove the experimental sticker off signatures and release that way in 5.36 (so you'd still have to `use feature` or `use v5.36`), but no other changes.
>  2. As for 1, but also add a runtime warning if you touch @_ inside a signatured-sub.
>  3. Like 2, but touching @_ is fatal.
>  4. Inside signatured-subs @_ becomes non-special.

I am strongly in favor of #1.

It's possible I misunderstand the core goals of not setting up @_.  I believe it's for performance.  Signatured subroutines can be made faster than subs sans sigs.  Instead of setting up @_ we can just not.  So if I am missing a large component, somebody should say something.

But:  the cost of this change is complexity at many levels.  First, the ongoing complexity of writing subroutines with @_.  "That's not complex, Rik, I've been doing that for twenty years!"  Great, but for people who haven't been doing it for 20 years, it *is* complex and also weird.

For those of us who have been writing subroutines with @_ for 20 years, removing @_ is also weird.  But *not* looking at @_ is pretty easy, so would we accept that tradeoff for some performance?  Yes.  But that tradeoff isn't actually on offer.  We don't have a branch that provides this tradeoff.  We have discussion over what one would be.  Mostly, it's #4 above:  accessing @_ is like accessing @~ or @(.  It's some meaningless global inside a signatured sub, left with the contents of the last old-style sub.  There's no warning for accessing it, because it's just some global.  In fact, my understanding is that adding a warning would require that we add magic to @_ globally, slowing down more or less all subroutines.  (Who remembers pseudohashes?)

So we can choose one the more complex versions of "make signatured subroutines faster" with no warnings, and do that *right away* and then remove the experimental flag after a year.  But we don't have that branch.  It's been the primary blocker on removing the experimental flag on signatures for years, I believe.  Meanwhile, the only people who get the vastly improved experience of having signatures on subroutines are the ones who are willing to ignore the "this is experimental and might change at any time" label — which is exactly the behavior we want to avoid encouraging.

That "slow everything down" problem means that #2 is probably off the table.

Let's talk about #1 again.  If we say "the signatures that you've had available for years, and that many of you have been using, are no longer experimental," then it's true: people can continue to see @_ in their subs, and that means that subroutine calls on signatured subs don't get the no-@_ optimization.  *Things stay the same speed as now*.  Meanwhile, the developer experience is significantly better.

If, later, we want to provide that optimization, we would need to provide a deprecation warning on accessing @_ in a subroutine with a signature.  Given my belief about this slowing down all subroutines, I don't think we're likely to remove @_ in signatured subroutines if we make them non-experimental as is right now, *and I am okay with that.*

We introduced signatures in 5.20, over seven years ago, and they're still experimental.  I think we're a lot better off making them non-experimental now and giving up on this optimization.  Further, I think that signatures are *so much *better than not that I think we should immediately add the signatures feature to the 5.36 feature bundle.

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