In article <1991May29.171209.14760@neon.Stanford.EDU> philip@pescadero.stanford.edu writes:
>.... But how many programs would break? I for one would be prepared
>to pay the price for the long-term gain, but I generally try to program
>as if boolean and int are distinct types, so the price wouldn't be
>very high for me.

The "break old code" argument against any changes is the one you hear
most often at the C++ standardization meetings.  It is of course
valid, but often over-used.  Even if there were incompatible changes,
every compiler would have a switch to get the old behaviour.

One of the strongest arguments in favour of a new boolean data type is
that you could do function overloading:

 void f(int);
 void f(boolean);

I also think a boolean data type would increase type safety in C++, at
least the way I program (:-).

I once tried to implement `class boolean' and failed.  Firstly there
was a performance problem, which I think good compilers could
overcome.  Secondly, I don't think I gained anything in type safety
and little in convenience: to be at all useful I needed implicit type
conversions int->boolean and boolean->int.  I think a boolean data
type should _not_ be another kind of integer (at least eventually) which
can be implicitly converted to/from int.  It should instead be a
unique enumerated type, but that doesn't work until all standard
functions (e.g., operator == (int, int)) return a boolean and not
an int.

The transition to a better world (:-) should be done in two phases:

 1.  Introduce the new built-in data type `boolean' (or
 whatever you call it), and specify that all standard
 operator == (etc.) return a boolean.

 2.  Include implicit type conversions between boolean and
 int, to minimize the number of broken programs.  I think
 this automatic conversion will help in most cases.

 3.  Warn about the automatic conversions and label them as
 anachronisms.

 4.  (Some years later) Turn the warnings of (3) into errors.

We had a similar case with C++ 2.0 with respect to handling of `enum',
and I think the transition was relatively painless.  The most common
problem was that people had used an enum for booleans, which caused
warning messages under the new interpretation.

Dag Br!"uck
--
Department of Automatic Control  E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118    Phone: +46 46-104287
S-221 00 Lund, SWEDEN   Fax:    +46 46-138118

In article <1991May30.060200.6590@lth.se> dag@control.lth.se (Dag Bruck) writes:

    void f(int);
    void f(boolean);

   I also think a boolean data type would increase type safety in C++, at
   least the way I program (:-).

   I once tried to implement `class boolean' and failed.  Firstly there
   was a performance problem, which I think good compilers could
   overcome.  Secondly, I don't think I gained anything in type safety
   and little in convenience: to be at all useful I needed implicit type
   conversions int->boolean and boolean->int.  I think a boolean data
   type should _not_ be another kind of integer (at least eventually) which
   can be implicitly converted to/from int.  It should instead be a
   unique enumerated type, but that doesn't work until all standard
   functions (e.g., operator == (int, int)) return a boolean and not
   an int.

I partly agree. It would be nice, if operator==(T,T) would return a
truly boolean value. On the other hand, it is possible to achieve the
same type safety if one implements not only a class boolean, but
classes real, integer, string, and what not, as well. That would of
course introduce a rather severe performance penalty, however. If only
current compilers did a better job in optimizing common
sub-expressions involving inlined access member functions and such... :-(

I know of at least one project, in which the group (they used Ada)
redefined practically everything, and to some extent succeeded. They
did peculiar things like had an "enum boolean { true, false, i_dont_care,
i_dont_know}" type of a construct.

Summa summarum: once again we face a consept that could be
incorporated to the language and indeed would fit in well, but without
which we can manage. IMHO, that means we shouldn't have it.
Especially, since no current library can support it.

   Dag Br!"uck
   --
   Department of Automatic Control  E-mail: dag@control.lth.se
   Lund Institute of Technology
   P. O. Box 118    Phone: +46 46-104287
   S-221 00 Lund, SWEDEN   Fax:    +46 46-138118


==pena
--
Olli-Matti Penttinen <pena@brainware.fi> | "When in doubt, use brute force."
Brainware Oy                             |    --Ken Thompson
P.O.Box 330                              +----------------------------------
02151  ESPOO, Finland       Tel. +358 0 4354 2565       Fax. +358 0 461 617

Defining your own Boolean type (with #defines, typedefs, or classes, as you
prefer) has advantages, but they are far outweighed by the problems
introduced when someone tries to use your code (or, conversely, when you're
trying to deal with code full of Booleans of one flavor or another).
What happens when you try to make use of two libraries, one of which thinks
Boolean is a "typedef int" and another which thinks Boolean is a class?
You could go through renaming and reworking, but that shouldn't be
necessary.

C++ inherits a pretty reasonable treatment of integers as Boolean values
from C (nonzero is True when evaluating, Boolean expressions evaluate to
integer 1 or 0).  It's portable, reasonably clean and flexible--for
instance, there's no other way to stuff multiple Booleans into a single
word, like you can with the : construct in C structures.  A little less
pretty than any of the ten thousand other ways people can think of to
deal with Boolean values, but unlike any of those, it's standard.

Overall, I think the disadvantages outweigh the advantages.  I hate
buying C source code and seeing Boolean defined explicitly.  It gets
ripped out as soon as a need develops to interface with it more than
perfunctorily.

--Nick
  npw@eleazar.dartmouth.edu