The Erlang Rationale - The problem with ‘if’

Sigh. If was added as an almost “on the spur of the moment” hack. We knew how to compile guards and thought it might be useful in the case where you don’t have a value to match against. As Erlang has pattern matching we found that a “pure” if is used less than in many other languages, we never used it much ourselves and therefore didn’t really worry much about it. This is not really that strange as in many languages if is used in way which resembles very trivial pattern matching. For example in C:

if ((x = get_some_value()) != 0) {
    do stuff with x
else {
    do some other stuff
}

Also I don’t really have a problem using case when I want to do a conditional, but then again I am so used to it I don't think about it.

There have been repeated suggestions and discussions of either extending if to allow user defined boolean functions or adding a new construct. The problem with extending if is that the tests would no longer be guard tests and would handle differently for exceptions. A guard test silently just fails while a normal expression generates an error, which would make the change incompatible. We actually made cond a reserved word but never got around to adding it to the language.