The optimizing behaviour further suggests that it's possible that ($var || 2) can evaluate as false - otherwise I would expect that (at least) the else{} would be optimized away.

You're giving the optimiser too much credit.

(I think; on the basis of the behaviour I've observed rather than analysis of the code) the optimiser has a relatively simple rule: if a conditional expression is a simple compile-time constant, it will optimise away any code that will never be reached as a result. Full stop.

It doesn't make any attempt to reduce a non-simple expression to a simple one:

$x = 1; if( $x ) { } else { }
^Z
$x = 1;
if ($x) {
    ();
}
else {
    ();
}
- syntax OK
[download]

Even:

C:\Users\HomeAdmin>perl -MO=Deparse
my $x = 1; if($x, 1){ } else{ }
^Z
my $x = 1;
if ($x, 1) {
    ();
}
else {
    ();
}
- syntax OK
[download]

Given that both branches of the if are empty; both of those ought to be reduced to just:$x;, just to cover the tied var side-effect case.

I think that the reality is not "the optimiser", but rather "a few, simple, optimisations".

There are hundreds of possibilities for compile time optimisations, but whilst the structure and formatting of the code remains so messy; it takes brave men to venture there looking for them.

You're giving the optimiser too much credit

Ok ... and I'm somewhat relieved about that :-)
But can ($var || 2) ever be false ?

The code provided initially by the OP was:

if ($var || 2) {
    # do stuff here
}
else {
    # won't do stuff 
}
[download]

If ($var || 2) is inevitably true, then that code is a rather silly (even obfuscating) construct.
All that was really needed was:

$var || 2;
# do stuff here
[download]

or simply:

$var;
# do stuff here
[download]

Is it safe for the OP to make such alterations, or do I overlook something ?
Afterthought: I'm actually now wondering whether the original code was in fact ($var | 2) and not ($var || 2)

Cheers,
Rob

But can ($var || 2) ever be false ?

No way I can see. So yes, the OPs code should be reducible to just $var; though that will produce a warning: Useless use of private variable in void context ....

And $var || 2; gets Useless use of a constant in void context ...

Replace the 2 with 1: $var || 1; to take advantage of a special case that produces no warning and deparses as:

C:\Users\HomeAdmin>perl -MO=Deparse -Mstrict -wle"my $var = 1; $var ||
+ 1;"
BEGIN { $^W = 1; }
BEGIN { $/ = "\n"; $\ = "\n"; }
use strict 'refs';
my $var = 1;
'???' unless $var;
-e syntax OK
[download]

Or:

1 if $var;
[download]

which achieves the same thing.

Or, if he's happy there are no ties involved, ditch the whole darn thing.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Nope, but a method of a tied variable could raise an exception or goto label.

A tied variable could also have side effects, like logging each access.

IOW the FETCH can't be short circuited, even if the result is of no interest.

Anyway optimizer rules are very simplistic, and if wanted such exotic edge cases could be forbidden in documentation.

Tied variables are hell for any optimizer, I remember a talk of Reini Urban in Kiev where he presented details of his optimizer with factor 2 speed gain. I was so puzzled how one technique works and asked how this can handle tied variables.

His answer was simple: tied variables are not allowed! :)

Anyway JS shows that JIT compiling is the way to go.

(NB no tied vars in ECMA JS)

update

There are several cases where optimization already causes strange effects.

For instance try to goto into a code chunk which is optimized away with 'if(0)'