Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
January 17, 2022 17:48
Subject:
Re: PSC #049 2022-01-07
Message ID:
f7bed73a-5561-4f87-abdf-341a0248c639@beta.fastmail.com
On Mon, Jan 17, 2022, at 7:31 AM, Dave Mitchell wrote:
> On Sun, Jan 09, 2022 at 11:33:29AM -0500, Ricardo Signes wrote:
> > 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.
> [snip] stuff
>
> There seems to be a lot of confusion and misconceptions present in this thread.
I am always glad to see either or both of those things cleared up!
> 1) leaving @_ untouched when calling a signatured-sub (i.e. it is still the @_ of the caller).
> [...]
> 2) To detect signature code which relies on @_ from breaking with this change, we also make the presence of @_, $_[...] etc within the *lexical scope* of a signatured sub a *compile* time warning. This is relatively easy to do (at least to catch most common cases) and has exactly *zero* run-time performance issues.
> [...]
> 3) to allow introspection and other processing of the args, introduce a new mechanism - either my 'query parameters' proposal or something else.
So far, I think I'm with you. (I guess that the idea here is that behavior that can't be detected at compile time won't issue a warning at runtime, right?)
> I would be strongly opposed to any final decision which didn't include (1) and (2).
>
> I would be uncomfortable with signatures becoming non-experimental until both (1) and (2) were done.
I have mixed feelings about both 1 and 2. I'd like to see the actual performance change. That said, I acknowledge generally what we said we'd be doing.
But we've said that for years, now, and it hasn't happened and signatures have remained an experiment. Without a change in hand, showing that we have the changes prepared and know they'll work, it feels like "we kept this in experimental for years, planning to do this. We didn't do it, but this year is different." Is this year different?
There are at least three possibilities ahead of us:
1. we ship signatures as non-experimental this year
2. we ship signatures as non-experimental next year, and it's faster and a little different
3. we skip #1 in favor of #2 but do neither
What I want most of all is to avoid #3.
Our policy on experiments is:
> Experimental features will only have their experimental status revoked when they no longer have any design-changing bugs open against them and when they have remained unchanged in behavior for the entire length of a development cycle.
So if we want to change how @_ works and then make the feature stable, we're obliged to get that change into 5.even.0 so we can release it as non-experimental in the next stable .0 release. Could we bend the rules? Yes, but all the better if we can get this change into 5.36 if we want stable in 5.38.
In fact, this is what I proposed (with a difference in the phase in which warning occurs) in November: http://markmail.org/message/23qppsq4qjmegq6m
…but it's January now, which makes me start to worry that we're not 1.5yr from stable signatures, but 2.5yr, or more worryingly, 1.5 plus n. This is also why I've said it seemed practical to look at shipping stable now with a warning that one aspect could not be relied upon. If no actual changes to the @_ handling were produced, we'd be in a better place. If they were, we'd have given warning.
When 5.36 comes out, it will be eight years since signature were added to the language. I just want to feel like I can tell people to use them without feeling like a hypocrite, because I also tell people we need to act like experiments are really unreliable.
--
rjbs
Thread Previous
|
Thread Next