Re: PSC #049 2022-01-07

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

Thread Previous | Thread Next

From:

Dave Mitchell

Date:

January 17, 2022 12:32

Subject:

Re: PSC #049 2022-01-07

Message ID:

YeVhsB8bsS1gBcQk@iabyn.com

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.

My preferred solution consists of doing all of the following:

1) leaving @_ untouched when calling a signatured-sub (i.e. it is still
the @_ of the caller).

This will have a significant performance boost, especially when calling
small stub functions like accessors. At the moment perl has to do the
equivalent of

    my @args = (...);
    local *_ = \@args;

for every sub call (even ones without args), setting up, aliasing,
unaliasing etc. It will also make assigning args to parameters faster.

Eventually over time as signatures become the norm, @_ will be remembered
just as some old weird thing perl used to do (like we occasionally
encounter perl4-isms).

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.

I think a warning (rather than being fatal) is best - it's compile time so
will catch most things during development, but still allows legitimate
uses of @_, e.g.:

    sub foo($x) {
        ....;
        no warnings 'snails';
        local @_ = (1,2,3);
        goto &bar; # tail call optimisation
    }

3) to allow introspection and other processing of the args, introduce a
new mechanism - either my 'query parameters' proposal or something else.

(3) can be done later as long as we're happy with the argument that "for
now, people should stick with the old sub syntax if they want access to
@_".

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 could live with (2) being done before (1). So I might accept:

5.36: - @_ gives compile-time warning of "don't use @_, subject to change".

5.38: - @_ gives compile-time warning of "don't use @_, no longer does what
         you think it does";
      - @_ stops being populated (i.e. it becomes still just caller's @_).
      - signatures stop being experimental

5.40: - query parameters (or similar) added.

5.40+  other signature features like named signatures added piecemeal.

Note that if (2) happens before (1), I think the warning shouldn't be a
deprecation warning - we don't want the category of the warning changing
after we implement (1). (Which, thinking about it, makes me more keen that
(1) and (2) happen together).

-- 
Decaffeinated coffee is like dehydrated water

Thread Previous | Thread Next