defined on HashofHash defines an element in the hash

[p5pRT]

Migrated from rt.perl.org#127712 (status was 'resolved')

Searchable as RT127712$

[p5pRT]

From 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

[p5pRT]

From @tonycoz

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.

You can avoid this behaviour by using the autovivication module from CPAN.

Tony

[1] that autovivication doesn't always respect lvalue vs rvalue

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @jkeenan

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},

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @jkeenan

On Mon Mar 14 15​:36​:44 2016, jkeenan wrote​:

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)

[p5pRT]

From @jkeenan

127712-defined.pl

[p5pRT]

From @pjcj

On Mon, Mar 14, 2016 at 03​:31​:02PM -0700, Tony Cook via RT wrote​:

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

[p5pRT]

From zefram@fysh.org

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

[p5pRT]

From @epa

Another possibility is to control the autovivification behaviour with
'use 5.24' and so on.

--
Ed Avis <eda@​waniasset.com>

[p5pRT]

From zefram@fysh.org

Ed Avis wrote​:

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

[p5pRT]

From @jkeenan

On Tue Mar 15 12​:31​:27 2016, zefram@​fysh.org wrote​:

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)

[p5pRT]

From zefram@fysh.org

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.

-zefram

[p5pRT]

From @pjcj

On Thu, Apr 21, 2016 at 03​:47​:25AM +0100, Zefram wrote​:

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

[p5pRT]

From zefram@fysh.org

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.

-zefram

[p5pRT]

From @pjcj

On Thu, Apr 21, 2016 at 12​:18​:41PM +0100, Zefram wrote​:

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