in reply to Re: dumb question
in thread post-increment and post-decrement behavior (was: dumb question)

I agree that this is a bug. But what is a better fix? I see two different potential fixes, with one common objective to make the interpretation of "print $a--" and "print $a++" consistant.

  1. make both to follow what is happening to post -- now, that is to treat $a as uninitialized, and issue a warining. This might be the only fix for some other languages in a similar case, but not Perl, and I personaly don't like this fix.
  2. Perl is special, and it is not uncommon for Perl to automatically initialize variables for you. Whatever it is post --, or post ++, Perl can predict $a as number, so Perl can just go ahead, and initialize $a to 0. This fix sounds more perlish to me, and I feel that it has a much greater consistancy with the rest part of Perl.

Try this code: 
$a --; # also try to coment this, and uncomment the next staement
#$a ++;
print $a; #either -1 or 1, depends on what you uncomment

[download]
In the above demo, whatever it is post --, or post ++, perl would initialied $a to 0, and this is what should happen to print $a-- and print $a++.

Replies are listed 'Best First'.
Re: Re: Re: dumb question
by jand (Friar) on Mar 16, 2003 at 05:58 UTC

    No, #1 is the correct fix. The postdecrement must return the value from before the decrement operation, which is undef.

    In your "fix" #2, how would you handle this situation:

    $a = 'a';
print $a--;

    [download]

    By your logic, it would also have to print '0', as Perl would predict it to be a number, and after the decrement $a is -1.

    However, I think it is pretty obvious that Perl must print 'a' here.

[reply]
[d/l]
      Obviously wrong. ;-) This is kind of apple and orange thing. The analogy you drew here is misleading ;-)

      1. In the case you given, there is no space left for prediction, as the value for $a is SET, CLEARLY SET. What kind of prediction is needed? why any prediction is needed? Why any kind of prediction is allowed?
      2. In the case I gave, i.e. the case which this thread is all about, the value of $a is undef, NOT SET, so there is this wild space left for perl to predict. And as I pointed out Perl does this kind of prediction all the time, when it is reasonable, not when it is obviously unreasonable.
[reply]
        No, you are wrong. :)

        Seriously, in your example $a is undef, which already has a meaning. If you look into perlsyn.pod, you'll find:

        A variable holds the undefined value (C<undef>) until it has been assigned a defined value, which is anything other than C<undef>. When used as a number, C<undef> is treated as C<0>; when used as a string, it is treated the empty string, C<"">; and when used as a reference that isn't being assigned to, it is treated as an error. If you enable warnings, you'll be notified of an uninitialized value whenever you treat C<undef> as a string or a number. Well, usually.

        Printing provides a string context, so $a must be treated as the empty string, and not as 0. That $a becomes a number after the print statement has completed is totally irrelevant in this discussion.

[reply]

In Section Seekers of Perl Wisdom