Re^3: order of operations with conditionals at the end

Replies are listed 'Best First'.
Re^4: order of operations with conditionals at the end by JavaFan (Canon) on Apr 04, 2012 at 20:51 UTC
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.` [download] "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.	[reply] [d/l]
Re^5: order of operations with conditionals at the end by AnomalousMonk (Archbishop) on Apr 04, 2012 at 21:22 UTC
... [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.	[reply]
Re^5: order of operations with conditionals at the end by ikegami (Patriarch) on Apr 04, 2012 at 21:16 UTC
"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.)	[reply]