[erlang-questions] Side-effects in "if" guards

[Richard Carlsson]

Darren New wrote:
> Is there a reason for this other than not having to define (and 
> implement) two different kinds of guards?

The main snag is that the rules for both syntax and semantics of
guards is subtly different from those of normal expressions, so
it's hard to extend what you can write in an if-guard in a way that
does not change the behaviour anywhere in all the existing code.

And even if you manage to do that, you'd likely end up with a very
complicated rule system for what you can write and what it means,
that nobody could keep track of, so in the interest of sanity, it
is probably best to leave it alone.

     /Richard