Re^2: What operator should perl5porters use for safe dereferencing? (->)

[tye]

I also strongly support the "make plain -> to be undef-safe" position. I've long found it frankly a design bug that using strict.pm means that $undef->{key} will either 1) silently create a hash or 2) die (depending on often-subtle issues of context).

My preference would be more like: Let me pick how de-ref'ing an undef behaves from 1) silent, 2) warn, or 3) die. Then, depending on my choice, $undef->{key} would pick (depending on context) between these paired choices of behaviors:

1. a) silently auto-vivify or b) silently return undef
2. a) auto-vivify with a warning or b) return undef with a warning
3. a) die or b) die

But, as a transition, it would be great if a future version of Perl 5 had default behaviors of:

1. w/o 'use strict': a) silently auto-vivify or b) silently return undef
2. w/ 'use strict': a) silently auto-vivify or b) return undef with a warning

(for extra clarity, 2b would be the only change.)

I almost always 'use strict;' and I almost always want $x = 'y'; $x->{z} to be fatal. But I very often don't want this to die:

sub routine {
    my( $arg, $opt ) = @_;
    blarg( $arg )
        if  $opt->{blargTheArg};
    ...
}

So I've gotten in the habit of writing ( $opt || {} )->{blarg} (after too many cases of code making it into Production before it ran into a case that resulted in $opt being undef).

So, it will be less work to form a habit of $opt&->{blarg} (or $opt->?{blarg}), but I'd much rather be able to declare that undef-> triggers a warning (in either context) and to have that be the default behavior in the context where the current behavior really just doesn't make a lot of sense.

On a side note, yes, I am aware of the autovivify module. I've long wanted that capability but I have no plans of using that module because the amount and complexity of XS code contained in it seems like a very inappropriate way to implement this feature (except as an experiment / proof of concept before it can be accepted into the 'core' -- which is what I consider this module) and has too high a risk of bizarre failures for the benefit provided, in my experience. I expect that one day the too-much and too-complex XS code of autovivify.xs will be completely replaced by some quite simple 'if' statements that examine 'hint bits' being sprinkled into a few places in Perl's own de-ref-implementing code and then I'll have a 'no autovivify;' that I can feel safe using.

Even better will be if the way that I declare 'de-ref'ing undef in an lvalue context generates a warning' at least can also declare the same (or similar) behavior for rvalue contexts.

[phaylon]

I don't think I'd have a big issue with this applying to hash and array refs. but ignoring method calls on undef by default is a big No-no for me. I'd definitely vote for it being a completely separate pragma then.

[tye]

Oh, yes. I agree with that.