Ternary Operator

In phix the ternary operator, also known (if you’ll forgive the redundant tautology) as an if-and-only-if expression, has a function-call-like syntax, allowing conditional selection with short-circuit evaluation, eg:
    iff(flag?"true":"false")
which, fairly obviously, yields "true" or "false" depending on the value of flag.

If you prefer, iif is exactly equivalent to iff, additionally comma separators are also valid:
    iif(<condition>,<expression1>,<expression2>)
However, for me, comma separators make it look too much like a normal function call and I would automatically assume eager evaluation.

The construct is a simplified form of the if statement with a single condition and an else clause, except that it has two expressions rather than two statement blocks, and not only utilises short-circuit evaluation within the condition, but also evaluates only one of the expressions (aka lazy evaluation [see Technicalia]). If the value of the condition can be determined at compile-time (possibly via constant propagation) then the compiler may only emit executable code for one of the expressions as well.

Note that some optimisations, especially pass-by-reference, can be thwarted by incorrect or excessive use of iff, for example
    s = iff(x<y?append(s,x):append(s,y))
is likely to be exponentially slower (you would still need millions of calls to notice) than the much neater and more obvious
    s = append(s,iff(x<y?x:y))
Often the result of an iff expression is best stored in a suitably named variable, to make the code easier to understand, and quite probably easier to debug, eg:
    s = append(s,iff(x<y?l-x*4:l-((x-1)*w+floor(y/w)*4))
vs:
    integer extra_space = iff(x<y?l-x*4:l-((x-1)*w+floor(y/w)*4)
    s = append(s,extra_space)
Such explicit clarifications normally incur no additional penalty whatsoever1 over the hidden unnamed temporary variable that the compiler would otherwise use anyway.

One more example (from builtins/regex.e)
    if greedy then
        code &= {SPLIT, i+3, nil}
    else
        code &= {SPLIT, nil, i+3}
    end if
has a certain clarity that, for me, gets lost in
    code &= {SPLIT, iff(greedy ? i+3 : nil ), iff(greedy ? nil : i+3 )}
I believe this (one of several possible variations) is somewhat better
    code &= iff(greedy ? {SPLIT, i+3, nil}
                       : {SPLIT, nil, i+3} )
nevertheless I still prefer the longhand/old school version - but use your own judgement, of course.

See Also: if, append