Some future Julia implementation could check a < c first (and probably a better strategy for speed). [I guess you’re saying the current 0.5 or 0.6 doesn’t] but while not done now, not ruled out in the future(?).
Comparison chaining for: a op b op c … is not defined for any possibly op-function, right, only a limited set e.g. <, <=, > etc. all functions that are transitive (and also defined as operators).
Limiting those functions to only transitive is a good idea, but can it (is?) be enforced? If not either the optimized can’t use the default, or it must figure out if had been overloaded and block optimizations otherwise. I’m not sure I would trust a compiler to be that brainy.
Since I’m here,
Footnote 2. on C++ (seemed insane), then I noticed 4. [Do you know the story behind it? Early versions of Fortran with eager, then short-circuit adopted from Lisp? Or is eager allowed (for old compatibility) but other allowed (considered a superset?); either used in the same compiler of different code parts?!]:
- When overloaded, the operators && and || are eager and can return any type.
[…] - Fortran operators are neither short-circuit nor eager: the
language specification allows the compiler to select the method for
optimization.