Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
January 10, 2022 14:57
Subject:
Re: PSC #049 2022-01-07
Message ID:
9d0a91ae-f469-4614-a1dc-b87648f9e3aa@beta.fastmail.com
On Mon, Jan 10, 2022, at 6:44 AM, Darren Duncan wrote:.
> When a file says "use v5.36" or a higher version, it causes signatures to be
> available non-experimentally AND it causes @_ to not be declared within the
> scope of any sub using a signature, wherein any references to @_ will fail AT
> PARSE/COMPILE time.
What about this code:
use v5.36.0;
sub foo ($x) {
# Here we have a runtime reference to @_ -- what happens?
my $first = substr $x, 0, 1;
no strict 'refs';
say "Contents of \@$first: @{$first}"; # What if $x was "_foo"?
}
Does this become a runtime failure?
How do we enforce that runtime failure? Presumably we do it by making reading from @_ require magic. Right now, @_ is a standard array, and it's subroutine entry that does the magical work of filling it in. If we make reading from it magic, it will become magic everywhere, slowing down all subroutine calls, right?
I don't think we're going to get to have a warning on this. We can stop setting up @_ and let people deal with the fallout — that is, not knowing what the heck happened until they find the entry in perlsub detailing that @_ now has the leavings of other subroutines in it — or we can give up and ship what we already have.
Or maybe something else I haven't imagined. But given the choices so far, I want to ship what we have.
--
rjbs
Thread Previous
|
Thread Next