TernaryOperator

• Phix
• Core Language
  • Atoms and Integers
  • Sequences and Strings
  • Phix vs Conventional Languages
  • Comments
  • Expressions
    • Relational Operators
    • Logical Operators
    • Arithmetic Operators
    • Sequence Operations
    • Ternary Operator
    • Subscripts
    • Slices
    • Concatenation
    • Sequence Formation
    • Other Operations on Sequences
    • Precedence Chart
  • Declarations
  • Statements
• Library Routines
• Other Libraries
• Recommended Tools
• Internals
• Glossary

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:

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:

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

is likely to be exponentially slower (you would still need millions of calls to notice) than the much neater and more obvious

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:

vs:

Such explicit clarifications normally incur no additional penalty whatsoever¹ over the hidden unnamed temporary variable that the compiler would otherwise use anyway.

One more example (from builtins\regex.e)

has a certain clarity that, for me, gets lost in

I believe this (one of several possible variations) is somewhat better

nevertheless I still prefer the longhand/old school version - but use your own judgement, of course.

There may also be cases such as iff(a:b?c:d:e:f), where the "a:", "c:", and "e:" are (automatically) treated as namespace qualifiers, that may be much clearer with (or even fail to compile without) extra parentheses, and/or comma separators, or otherwise simply ought and deserve to be a more traditional if-construct.

The Euphoria implementation of iff does not perform lazy evaluation, instead both expressions are evaluated but only one result used. Hence some uses of iff() that are perfectly valid in Phix will need to be rewritten in longhand form (if .. then .. else .. end if) in order to be compatible with Euphoria.

¹(no additional penalty whatsoever) Admittedly one of the executables would be a few bytes larger (~0.001%), because somewhere, for debugging purposes, it contains the name "extra_space" instead of -1, without doubt entirely justified if it eases the development cost or maintenance burden in any way, but otherwise you would be very hard pressed indeed to devise an experiment that showed any other measurable difference.