TITLE: Another reason NOT to define a boolean enum


RESPONSE: kbennett@access.digex.net (Keith R. Bennett)

I am currently working on a project where the former leader defined an
enum BOOLEAN { FALSE = 0, TRUE = 1 }.  The problem with this is that
it requires verbosity that contributes little if anything to the
clarity of the code.  


RESPONSE: maxtal@physics.su.OZ.AU (John Max Skaller), 29 Jul 93

	Worse! The committee has now allowed overloading on
enum types. That means

	f(boolean);
	f(a<b); // error

since the conversion int-->boolean requires an explicit cast.
(ARM p114). The reason is obvious:

	enum YesNo {Yes, No} answer;
	f(answer);
	f(1); // boolean or answer?
	      // neither!

[ There have been some lively discussions about creating a boolean
  enum or boolean class. Most (if not all) of these schemes had 
  severe shortcommings. -adc ]