in reply to Re: order of operations with conditionals at the end
in thread order of operations with conditionals at the end

Not allowed?
$ perl5.15.9 -wE 'my $x = 1 if 2; say $x // "???"' 1 $ perl5.15.9 -wE 'my $x = 1 if 0; say $x // "???"' ??? $
I won't recommend it, but it is still allowed. I thought it started warning under certain conditions since 5.14, but I'm not able to reproduce it.

Replies are listed 'Best First'.
Re^3: order of operations with conditionals at the end
by ikegami (Patriarch) on Apr 04, 2012 at 20:01 UTC
    The compiler does compile it, but it has been explicitly forbidden in the docs, and it has been so for far far longer than 5.14. (I'm guessing 5.6 or 5.8.)
      Hmmm, the closest I could find is:
      B<NOTE:> The behaviour of a C<my>, C<state>, or C<our> modified with a statement modifier conditional or loop construct (for example, C<my $x if ...>) is B<undefined>. The value of the C<my> variable may be C<undef>, any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.
      "Undefined behaviour", "may change in the future", "don't rely on it", and "here be dragons" are all hints not to use it. But it doesn't add up to "explicitly forbidden in the docs" in my book.
        ... [don't] add up to "explicitly forbidden in the docs" ...

        They don't explicitly add up to "explicitly forbidden in the docs," but if I saw such phrases in any documentation, I would be extremely reluctant to go anywhere near the pertinent construct. There be old, aching scars.

        "Undefined behaviour" means it's perfectly acceptable for the call to delete all the files on your hard drive if you use it. If you're arguing that's acceptable, then sure, you're not technically forbidden from using it.

        (No, I'm not exaggerating. A program crashing did exactly that to me once.)