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

Discourage @_ in signatured subroutine

Thread Next
Paul "LeoNerd" Evans
January 16, 2022 15:41
Discourage @_ in signatured subroutine
Message ID:
I've started a branch to add a discouragement warning when people try
to rely on the @_ array inside a signatured sub:

For instance, while not using a signatured sub this is fine:

  ./perl -Ilib -Mexperimental=signatures -ce \
    'sub f { my $self = shift; print @_; }'

  -e syntax OK

If the sub has a signature it prints warnings at compiletime:

  $ ./perl -Ilib -Mexperimental=signatures -ce \
    'sub f($x) { my $self = shift; print @_; }'

  Implicit use of @_ in shift is discouraged in signatured subroutine at -e line 1.
  Use of @_ in print is discouraged in signatured subroutine at -e line 1.
  -e syntax OK

The PR is still draft as it still needs a bit more work on it (see the
notes in the PR itself).

Notably, this relates to the recent "de-experimentalise signatures"
discussions in a few ways:

  *) It's a compile-time warning, it has no runtime effect
  *) It's only a warning, it does not change the current behaviour

To stress again - it doesn't alter any behaviour, other than printing
some warnings at compiletime. Runtime performance remains exactly as it
was, and any code that provokes these warnings still works as it
currently does.

Additionally, as it's simply a warning intended to draw attention to
"you probably don't want to do that" situations, it doesn't have to be
perfect and cover all the bases. In particular there is at least one
known situation that it can't see:

  $ ./perl -Ilib -Mexperimental=signatures -e \
    'sub f($x) {
      my $splat = "_";
      no strict 'refs';
      my $y = shift @$splat;
      print "x=$x y=$y\n"; }

  x=123 y=123

It doesn't have to perfect. It just has to warn people who are dipping
their toes into signatures that we *may* change the behaviour of @_ at
some further point down the line, so they probably don't want to do
what they're currently doing.

I believe this still fits in with option 1 of our plan:

  > 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.

because additionally, we can always add discouragement/deprecation
warnings at any time, without otherwise upsetting the "experimental"
status of a feature.

Thoughts, anyone?

Paul "LeoNerd" Evans      |  |

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