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

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.

Comment on Re^4: order of operations with conditionals at the end Download Code

Replies are listed 'Best First'.
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]