Skip Menu |
Report information
Id: 127712
Status: pending release
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: phberninger [at] gmx.net
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: defined on HashofHash defines an element in the hash
Date: Mon, 14 Mar 2016 17:45:16 +0100
To: perlbug [...] perl.org
From: "Philipp Berninger" <phberninger [...] gmx.net>
Checking with defined for an Hash of Hash element defines the element in the hash, instead of returning undefined:
The following code will reproduce it:
 
perl -e 'if(defined($foo{"a"}{"b"})){ print "not defined\n";}if(defined($foo{"a"})){ print "ERROR? now defined?\n";}   '
 
I hope it is not a feature. tested with perl 5.20.2 under Linux
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 654b
On Mon Mar 14 09:45:35 2016, phberninger@gmx.net wrote: Show quoted text
> Checking with defined for an Hash of Hash element defines the element > in the > hash, instead of returning undefined:The following code will reproduce > it: perl > -e 'if(defined($foo{"a"}{"b"})){ print "not > defined\n";}if(defined($foo{"a"})){ > print "ERROR? now defined?\n";} ' I hope it is not a feature. tested > with perl > 5.20.2 under Linux
This is a known problem[1], and is difficult to fix because the change would break existing code. You can avoid this behaviour by using the autovivication module from CPAN. Tony [1] that autovivication doesn't always respect lvalue vs rvalue
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 566b
On Mon Mar 14 09:45:35 2016, phberninger@gmx.net wrote: Show quoted text
> Checking with defined for an Hash of Hash element defines the element > in the > hash, instead of returning undefined:The following code will reproduce > it: perl > -e 'if(defined($foo{"a"}{"b"})){ print "not > defined\n";}if(defined($foo{"a"})){ > print "ERROR? now defined?\n";} ' I hope it is not a feature. tested > with perl > 5.20.2 under Linux
I do not believe this is a bug. The test for definedness of $foo{a}{b} in the first 'if' block autovivifies $foo{a}, -- James E Keenan (jkeenan@cpan.org)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 686b
On Mon Mar 14 15:36:44 2016, jkeenan wrote: Show quoted text
> On Mon Mar 14 09:45:35 2016, phberninger@gmx.net wrote:
> > Checking with defined for an Hash of Hash element defines the element > > in the > > hash, instead of returning undefined:The following code will > > reproduce > > it: perl > > -e 'if(defined($foo{"a"}{"b"})){ print "not > > defined\n";}if(defined($foo{"a"})){ > > print "ERROR? now defined?\n";} ' I hope it is not a feature. tested > > with perl > > 5.20.2 under Linux
> > I do not believe this is a bug. > > The test for definedness of $foo{a}{b} in the first 'if' block > autovivifies $foo{a},
That post was incomplete. See attached. -- James E Keenan (jkeenan@cpan.org)
Subject: 127712-defined.pl
Download 127712-defined.pl
text/x-perl 369b
# perl use strict; use warnings; my %foo; if(defined($foo{"a"}{"b"})){ print 'AAA: $foo{"a"}{"b"} is now defined', "\n"; } else { print 'BBB: $foo{"a"}{"b"} is not yet defined', "\n"; } if(defined($foo{"a"})){ print 'CCC: $foo{"a"} was autovivified in the test for definedness above', "\n"; } else { print 'DDD: $foo{"a"} is not yet defined', "\n"; }
From: Paul Johnson <paul [...] pjcj.net>
To: Tony Cook via RT <perlbug-followup [...] perl.org>
Date: Tue, 15 Mar 2016 16:52:40 +0100
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Mon, Mar 14, 2016 at 03:31:02PM -0700, Tony Cook via RT wrote: Show quoted text
> On Mon Mar 14 09:45:35 2016, phberninger@gmx.net wrote:
> > Checking with defined for an Hash of Hash element defines the element > > in the > > hash, instead of returning undefined:The following code will reproduce > > it: perl > > -e 'if(defined($foo{"a"}{"b"})){ print "not > > defined\n";}if(defined($foo{"a"})){ > > print "ERROR? now defined?\n";} ' I hope it is not a feature. tested > > with perl > > 5.20.2 under Linux
> > This is a known problem[1], and is difficult to fix because the change would break existing code.
Break, in the sense of altering. But this is the case for all bug fixes. Since the last century the following has appeared in perlfunc: This surprising autovivification in what does not at first--or even second--glance appear to be an lvalue context may be fixed in a future release. Now, this bug has existed for a long time and therefore is in a slightly different category to a bug in a new feature, for example, which gets fixed a release or two later. But are we seriously saying that we cannot fix this now because, we assume, too much code would change behaviour? If that is the case, then the documentation should be updated to reflect this policy. If not, Tony makes it sound as though it is otherwise not difficult to fix. That was not my understanding, but if it is so, then should we not fix it? If we would still like to fix it but cannot at the moment, for some other reason, then things stay as they are. Which case do we have here? -- Paul Johnson - paul@pjcj.net http://www.pjcj.net
Date: Tue, 15 Mar 2016 19:30:48 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
Download (untitled) / with headers
text/plain 353b
Paul Johnson wrote: Show quoted text
> are we seriously saying that we >cannot fix this now because, we assume, too much code would change >behaviour? > >If that is the case, then the documentation should be updated to reflect >this policy.
Yes, we should document that the (default) autovivification behaviour won't change. -zefram
Date: Wed, 16 Mar 2016 11:08:42 +0000 (UTC)
To: perl5-porters [...] perl.org
From: Ed Avis <eda [...] waniasset.com>
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
Download (untitled) / with headers
text/plain 126b
Another possibility is to control the autovivification behaviour with 'use 5.24' and so on. -- Ed Avis <eda@waniasset.com>
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Date: Wed, 16 Mar 2016 11:22:45 +0000
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
Download (untitled) / with headers
text/plain 411b
Ed Avis wrote: Show quoted text
>Another possibility is to control the autovivification behaviour with >'use 5.24' and so on.
Absolutely. There is a prototype of this on CPAN, autovivification.pm, and this kind of effect seems a good candidate to be incorporated into the core. It'd have to have an independently-settable pragmatic flag, which can then be incorporated into one of the perl-version feature bundles. -zefram
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 639b
On Tue Mar 15 12:31:27 2016, zefram@fysh.org wrote: Show quoted text
> Paul Johnson wrote:
> > are we seriously saying that we > >cannot fix this now because, we assume, too much code would change > >behaviour? > > > >If that is the case, then the documentation should be updated to reflect > >this policy.
> > Yes, we should document that the (default) autovivification behaviour > won't change. > > -zefram >
Paul, zefram, et. al.: Could someone propose some wording for this documentation clarification? That would help move this ticket toward closing. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
Date: Thu, 21 Apr 2016 03:47:25 +0100
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 334b
James E Keenan via RT wrote: Show quoted text
>Could someone propose some wording for this documentation clarification?
In perlfunc.pod, section on "exists", delete the paragraph This surprising autovivification in what does not at first--or even second--glance appear to be an lvalue context may be fixed in a future release. -zefram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
Date: Thu, 21 Apr 2016 13:11:55 +0200
To: Zefram <zefram [...] fysh.org>
From: Paul Johnson <paul [...] pjcj.net>
Download (untitled) / with headers
text/plain 728b
On Thu, Apr 21, 2016 at 03:47:25AM +0100, Zefram wrote: Show quoted text
> James E Keenan via RT wrote:
> >Could someone propose some wording for this documentation clarification?
> > In perlfunc.pod, section on "exists", delete the paragraph > > This surprising autovivification in what does not at first--or even > second--glance appear to be an lvalue context may be fixed in a future > release.
It is disappointing that this language wart seems to be here to stay. Is there any way that it could be fixed under "use feature" or "use 5.26" for example? Can anyone think of a good solution here? If not then yes, just deleting the caveat from the docs seems appropriate. -- Paul Johnson - paul@pjcj.net http://www.pjcj.net
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
Date: Thu, 21 Apr 2016 12:18:41 +0100
From: Zefram <zefram [...] fysh.org>
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 268b
Paul Johnson wrote: Show quoted text
>Is there any way that it could be fixed under "use feature" or "use >5.26" for example?
Yes. A feature flag would be a fine way to switch to different autovivification semantics, and it could go into a version bundle. Patches welcome. -zefram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
Date: Thu, 21 Apr 2016 13:42:41 +0200
From: Paul Johnson <paul [...] pjcj.net>
To: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 478b
On Thu, Apr 21, 2016 at 12:18:41PM +0100, Zefram wrote: Show quoted text
> Paul Johnson wrote:
> >Is there any way that it could be fixed under "use feature" or "use > >5.26" for example?
> > Yes. A feature flag would be a fine way to switch to different > autovivification semantics, and it could go into a version bundle. > Patches welcome.
In which case, perhaps, deleting the caveat from the documentation may be somewhat premature. -- Paul Johnson - paul@pjcj.net http://www.pjcj.net
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
From: Zefram <zefram [...] fysh.org>
To: perl5-porters [...] perl.org
Date: Thu, 21 Apr 2016 12:56:45 +0100
Download (untitled) / with headers
text/plain 485b
Paul Johnson wrote: Show quoted text
>In which case, perhaps, deleting the caveat from the documentation may >be somewhat premature.
The caveat is warning about possible changes in behaviour of existing code, and we're ruling that out. If we were to have anything in the documentation referring to the possible future feature flag, it would need different wording, and ought to be relocated to perlref(1). But for the most part we don't sprinkle our wishlist throughout the documentation. -zefram
To: perl5-porters [...] perl.org
Date: Tue, 5 Dec 2017 18:06:05 +0000
Subject: Re: [perl #127712] defined on HashofHash defines an element in the hash
From: Zefram <zefram [...] fysh.org>
Documentation updated in commit d3f0c815eccb54ae88550259c06aa395b2274580. -zefram


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org