Language Design – Why Implication is Not Included as a Logical Operator

language-design

It might be a strange question, but why there is no implication as a logical operator in many languages (Java, C, C++, Python Haskell – although as last one have user defined operators its trivial to add it)? I find logical implication much clearer to write (particularly in asserts or assert-like expressions) then negation with or:

encrypt(buf, key, mode, iv = null) {
    assert (mode != ECB --> iv != null);
    assert (mode == ECB || iv != null);
    assert (implies(mode != ECB, iv != null)); // User-defined function
}

Best Answer

It could be useful to have sometimes, no doubt. Several points argue against such an operator:

  • The characters - and > are valuable, both in isolation and combined. Many languages already use them to mean other things. (And many can't use unicode character sets for their syntax.)
  • Implication is very counter-intuitive, even to logic-minded people such as programmers. The fact that three out of the four truth table entries are true surprises many people.
  • All other logical operators are symmetrical, which would make -> an exception to orthogonality.
  • At the same time, there is an easy workaround: use operators ! and ||.
  • Implication is used vastly less often than logical and/or.

This is probably why the operator is rare today. Certainly it could become more common, as new dynamic languages use Unicode for everything and operator overloading becomes more fashionable again.