develooper Front page | perl.perl5.porters | Postings from August 2019

[perl #134138] Eliminate modifiable variables in constants

Thread Previous
From:
James E Keenan via RT
Date:
August 9, 2019 21:30
Subject:
[perl #134138] Eliminate modifiable variables in constants
Message ID:
rt-4.0.24-5528-1565386191-89.134138-15-0@perl.org
On Wed, 05 Jun 2019 01:35:47 GMT, tonyc wrote:
> On Tue, 04 Jun 2019 18:22:38 -0700, jkeenan wrote:
> > On Wed, 05 Jun 2019 01:10:06 GMT, tonyc wrote:
> > > On Sat, 25 May 2019 19:30:56 -0700, jkeenan wrote:
> > > > On Sat, 25 May 2019 02:03:40 GMT, jkeenan@pobox.com wrote:
> > > > > pod/perldeprecation.pod contains the following entry:
> > > > >
> > > > > #####
> > > > > Constants from lexical variables potentially modified
> > > > > elsewhere
> > > > >
> > > > > You wrote something like
> > > > >
> > > > > my $var; $sub = sub () { $var };
> > > > >
> > > > > but $var is referenced elsewhere and could be modified
> > > > > after the "sub" expression is evaluated. Either it is
> > > > > explicitly modified elsewhere ("$var = 3") or it is passed
> > > > > to a subroutine or to an operator like "printf" or "map",
> > > > > which may or may not modify the variable.
> > > > >
> > > > > Traditionally, Perl has captured the value of the variable
> > > > > at that point and turned the subroutine into a constant
> > > > > eligible for inlining. In those cases where the variable
> > > > > can be modified elsewhere, this breaks the behavior of
> > > > > closures, in which the subroutine captures the variable
> > > > > itself, rather than its value, so future changes to the
> > > > > variable are reflected in the subroutine's return value.
> > > > >
> > > > > If you intended for the subroutine to be eligible for
> > > > > inlining, then make sure the variable is not referenced
> > > > > elsewhere, possibly by copying it:
> > > > >
> > > > > my $var2 = $var; $sub = sub () { $var2 };
> > > > >
> > > > > If you do want this subroutine to be a closure that
> > > > > reflects future changes to the variable that it closes
> > > > > over, add an explicit "return":
> > > > >
> > > > > my $var; $sub = sub () { return $var };
> > > > >
> > > > > This usage has been deprecated, and will no longer be
> > > > > allowed in Perl 5.32.
> > > > > #####
> > > > >
> > > > > The entry was made in this commit:
> > > > >
> > > > > #####
> > > > > commit 9840d1d66ee1648f6d7fb1554101450158cfee16
> > > > > Author: Abigail <abigail@abigail.be>
> > > > > Date:   Sat Jan 14 18:25:48 2017 +0100
> > > > >
> > > > > Deprecating the modifyable variables in constants by 5.32.
> > > > >
> > > > > It was already deprecated, but we're now adding a version
> > > > > number.
> > > > > #####
> > > > >
> > > > > Make it so.
> > > >
> > > > Please review patch attached, which is smoking in this branch:
> > > >
> > > > smoke-me/jkeenan/rt-134138-constants-in-variable
> > > >
> > > > Thank you very much.
> > >
> > > I'm not sure this is the desired behaviour, though maybe we do want
> > > it
> > > fatal for a release or two to ensure any code that depends on the
> > > old
> > > behaviour is updated.
> > >
> > > As to your patch, you've left code in after the croak() that will
> > > no
> > > longer be executed (and since copied can no longer be true, some
> > > other
> > > code can be removed.)
> > >
> > > So there's two issues:
> > >
> > > a) should sub () { $x } return the current value of $x or croak at
> > > compile-time
> > >
> > > b) if we croak at compile-time, the patch needs work
> > >
> >
> > Well, I was just coding to see if I could change the deprecation to a
> > fatalization.  I don't really understand the code, so we don't have
> > to
> > go forward with this patch.
> >
> > But with (a) you seem to be suggesting that we need a better
> > understanding of what we *should* be doing.  What would that be?
> 
> I expect making it fatal will be the right choice at least for now.
> 
> Making 'sub () {$x}' behave as the code reads may break code that
> expects the old behaviour where the warnings have been suppressed or
> possibly only seen by end users.
> 
> Making it fatal (especially at compile-time, as we do) will prevent
> that.
> 
> But the const-ifying behaviour has been deprecated for a while now.
> 
> I don't know what the intent was when it was originally deprecated.
> 
> Tony

Can we reformulate the "ask" in this ticket so that we know what we want to deliver in perl-5.32?

Thank you very much.
-- 
James E Keenan (jkeenan@cpan.org)

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134138

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About