in reply to Re: When DOESN'T "Use of uninitialized value" show up?
in thread When DOESN'T "Use of uninitialized value" show up?

undef is false by definition in Perl and so is absolutely fine whenever in a boolean context.

"By definition" doesn't help explain it. For example, undef is interpreted as 0 by definition in a numeric context, but I nevertheless get "Use of uninitialized value" for 1 + undef.

perldiag, explaining the message, just says 'An undefined value was used as if it were already defined. It was interpreted as a "" or a 0, but maybe it was a mistake.' Since there is no qualifier on "used", I interpreted it to include use in a boolean context. I'd love to know where it might be clarified in documentation.

Hmm, now looking at it again, maybe the second sentence is the real rule (so the first is a misleading summary): you get the warning if and only if, due to the operation it's being used in, Perl has to convert an undef value to a string ("") or number (0)? If so, I still think that undef->{anything} not causing an error is a bad design, and other uses in an rvalue context might be. Personally, I want it to complain about any use of an undefined value.

What contexts are there for use of undef? Converting to a string, converting to a string, assignment, boolean, dereferencing via ->, ... any others?

Sub call?

$ perl -e 'my $x = undef; &$x("frog")' Undefined subroutine &main:: called at -e line 1.

I guess that's a conversion to a string instead of a bad reference -- like an eval rather than like undef->{...}.

Replies are listed 'Best First'.
Re^3: When DOESN'T "Use of uninitialized value" show up?
by ikegami (Patriarch) on Dec 16, 2011 at 08:08 UTC

    you get the warning if and only if, due to the operation it's being used in, Perl has to convert an undef value to a string ("") or number (0)?

    Bingo.

    Addition wants a number. If you don't pass a number, the value gets coerced into a number. Coercions from undef warn.

    A truth test doesn't require or cause coercion, so there's no coercion that can warn.

    What contexts are there for use of undef?

    What does that mean? Are you asking what behaviour an operator can take when passed undef as one of its operand? Well, that's entirely up to the operator.

    Personally, I want it to complain about any use of an undefined value.

    That's so wrong. Paradoxically, making the use of undefined values always warn will have a net *drop* in useful warnings.

    People use undefined values because they know warnings will occur if it's misused. If using undefined values always warns, a different value that never warns will be used instead.

    Not to mention it's silly to have defined($undef), my $x = undef; and my $x = 123; warn.

    You might be interested in no autovivfication;, though.

      Personally, I want it to complain about any use of an undefined value.

      That's so wrong. Paradoxically, making the use of undefined values always warn will have a net *drop* in useful warnings.

      People use undefined values because they know warnings will occur if it's misused. If using undefined values always warns, a different value that never warns will be used instead.

      It's true that having more warnings may turn people off and cause them to turn warnings off. Someone in my office did that right now, and I think it was for no warnings 'uninitialized'.

      Nevertheless, I don't often use uninitialized values as actual values, and when I do, I check for it being !defined before using it further. So I want more restrictions on the use of uninitialized values. I would prefer if all arithmetic on undef values threw a warning, for example, or use in a boolean context.

      Not to mention it's silly to have defined($undef), my $x = undef; and my $x = 123; warn.

      Thank you for pointing out defined(): since it's defined to deal with undef, certainly it should not throw a warning with undef! Similarly with //, and exists is arguably in the same class.

      However, "my $x = undef" is equivalent to "my $x" or even "undef my $x". And I don't consider "my $x = 123;" to use undef at all: in this context, you can't tell that $x was ever assigned undef, and even if it was, that value is never referenced but is instead stomped out of existence.

      In C, the term I'm looking for is "rvalue": I would like warnings whenever I try to access the value of undef.

      Thank you for the pointer to "no autovivification;" I don't know any details about autovivification and I need to look it up.

        Nevertheless, I don't often use uninitialized values as actual values

        You never optional fields in your data structures? You never use optional parameters? You never use output parameters (e.g. open)?

        I use undefined values every 5 lines of code, I bet. Yes, you're telling me that one in five of my lines of code should warn.

        And I don't consider "my $x = 123;" to use undef at all: in this context

        That may be, but it is. You're doing sassign($x, 123) and $x is undefined, and you indicated you want all undefined operands to warn.

        since it's defined to deal with undef, certainly it should not throw a warning with undef!

        And of course, so are truth tests.

        Thank god. I thought you wanted us to use

        if (exists($h{x} && defined($h{x}) && $h{x})

        instead of

        if ($h{x})

        I would like warnings whenever I try to access the value of undef.

        Except you said you don't want those that expect undef as an argument to warn, so I don't know of a single thing you think should start warning that doesn't already.

        Update: I just thought one. You surely want length($undef) to warn. That used to be the case, but that got fixed.

        This way, the common check

        if (defined($s) && length($s))

        can be written as

        if (length($s))

        And it doesn't hurt since you still get a warning (instead of two) if you use length wrong.

        my $length = length($undef); # Used to warn here. print $length; # Still warn here. my $length = length($undef); # Used to warn here. for (1..$length) # Still warn here. my $length = length($undef); # Used to warn here. pack 'N', $length # Still warn here. ...

        As far as I can tell, the only change you want to have done is to remove a small but awesome improvement to Perl.