From: Dennis Ritchie <dmr@bell-labs.com>
Newsgroups: comp.std.c
Subject: Re: logical exclusive OR
Date: Wed, 10 Jun 1998 03:49:12 +0100

Although this discussion has mostly died down, this
is submitted in case there is interest.  The
file it's from is dated 1995 though that might
be when it was last copied; I didn't retain the date
on the mail that it recorded.  It might well be
quoted in Steve S's online or published FAQ.

	Dennis


Subject: Re: A question of C history
To: XX@menlo.com (XXX)
To: scs@eskimo.com (Steve Summit)

XX asked:
  I teach C programming classes, and I'm often asked why
 C has a bitwise exclusive-OR operator but not a logical one.
 Is this simply an historical accident, or was there a
 specific reason it was omitted?  Also, is there any reason
 why the C9x committee shouldn't consider
 adding it to the standard?


I've often been asked
this in person, and it comes up on netnews too.
Since I formulated a mildly coherent answer, I
'm sending it along to Steve in case a suitably edited
version is suitable for the C FAQ.

--
Answer:
There are both historical and practical reasons why there is no ^^
operator.  The practical is: there's not much use for the
operator.  The main point of && and || is to take
advantage of their short-circuit evaluation not only for efficiency
reasons, but more often for expressiveness and
correctness. For example, in

  if (cond1() && cond2()) ...

it is often important that cond1() is done first, because if it's false
cond2() may not be well defined, or because cond1() is cheap and
cond2() is expensive.  Syntax to handle the situation has made it into
lots of languages; compare Ada's "and then'. By contrast, an ^^
operator would always force evaluation of both arms of the expression,
so there's no efficiency gain.  Furthermore, situations in which ^^ is
really called for are pretty rare, though examples can be created.
These situations get rarer and stranger as you stack up the operator--

  if (cond1() ^^ cond2() ^^ cond3() ^^ ...) ...

does the consequent exactly when an odd number of the condx()s
are true.   By contrast, the && and || analogs remain fairly plausible
and useful.

Historical:  C's predecessors (B and BCPL) had only the bitwise
versions of | & ^.   They also had a special rule, namely that in an
statement like

	if (a & b) ...

the '&", being at the 'top level' of the expression occurring  in
`truth-value context' (inside the if())  was interpreted just
like C's &&.  Similarly for |. But not so for ^.

One of the early bits of C evolution was the creation of separate
&& and || operators.  This was better than the special rule, which was
hard to explain.

In other words, the whole question arises because of the particular
method of symmetry-breaking that C chose.   Suppose I had reacted to
the situation of BCPL and B taking their notion of

	if (a & b) ...

and had people say

	if (a) andif (b) ...

(and similarly with "orif")  One can make a case that this kind of
syntax is better than && and ||,   If it had happened,
would people be asking for "xorif"? Probably not.

My guess is that &, &&; |,||; ^,^^ is a false symmetry.  But it's
one that people seem to want, and, though it's not much help,
adding it wouldn't do much harm.

	Dennis