From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: New C++ type: boole
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 27 Jul 1992 04:44:30 GMT

The following is actually from Deviasse Robert N <a228devi@cdf.toronto.edu>.
I am posting it for him, since he does not have write access to the net.
Disclaimer: if you don't like it, blame him! :-)

	Fergus.

========================== PROPOSAL FOLLOWS =============================

Actually there is a general way of adding a boole type without breaking any
C++ code. Every DOS compiler I've used (and a few UNIX ones) already give
warning for code such as "if (ch=getchar()) /*...*/;". Such warnings could
easiliy be made manditory in the standard, or the standard could reserve
a pragma that does this type of checking, though the implementation may
choose not to implement it. Market pressure would probably force most
compilers (the ones that do no implement this feature yet) to implement
the macros anyway, although they need not. This alone would go a long
way towards providing the benefits of a boolean type "universally". However,
there are other cases that would be nice to fix. What most of us would like 
is protection from the following type of situation:
   void f(int x) { /*...*/ }
   void f(BOOL y) { /*...*/ }

   f(a==b);  /* OOPS, wrong f() called!!! */

The simplest way to avoid this situation is if BOOL were declared "int",
since the second f() would be illegal. This is really not so significant
since it is very rare for both function overloadings to be intentionally
needed. However, if BOOL==int then we lose a lot of the nice properties
of BOOL being an enum, such as the need for explicit casts. What we need
is an enum that protects us from unintentional mistakes like the above.

Suppose we modify the enum construct to the following form

   enum <integral_type> <id> { id < = value > { , id < = value > } ;
   ----                      -      -           -      -         - -

   where an underlined word is a keyword or punctuation,
       < A >  means that A is optional
       { A }  means that A is repeated 0 or more times

The semantics of this new enum would be that during overload resolution of
a function, the enum would conflict with integral_type. However, no automatic
conversion between enum and integral_type would occur beyond what is
presently allowed in C++. Also, to make this type of enum more useful, the
enum would have exactly the same size as the integral_type and have it's
enumerations represented in the type of the integral_type. Thus one could
use these enumerated types in structures that required enumerated types of
the given size.

So that if we define:
     enum int BOOL { FALSE, TRUE };

then the following produce errors:
   void f(int x) { /*...*/ }
   void f(BOOL y) { /*...*/ }   /* error: conflicts with f(int) */

similarly
   void f(BOOL y) { /*...*/ }
   f(BOOL(a==b));
would require a cast.

It would be nice if we had such an enumerated type in the standard library,
perhaps in <boolean.h> of the following form.
   enum int Boole { boole_false, boole_true };
This would reduce the number of different flavours of boolean types that
programmers currently define.


I think that most people would like to have a boolean type in C++, although
most people have resigned themselves to thinking that boolean types
cannot easily be added to C++.

I thing this is a fair workable compromise that allows the programmer
to protect him/her self without turning the semantics of C++ inside-out.
True, the above is a "humpty-dumpty" enum, but then what's wrong with
Humpty-Dumpty, many computer science books quote from Lewis Carol :-)

------
I don't have write-access to the net, although I have no problem reading
from the net.

BTW, I'm not going to write to the ANSI committee to extend the C++
language to add this type of enum, I'm far too busy. If someone else
wants to pick up this proposal, then be my guest. Otherwise, please
post this proposal to /dev/nul.

/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: a228devi@cdf.toronto.edu  |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/
Xref: sparky comp.lang.c++:11281 comp.lang.c:11412