NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/cplus/11574

Text File | 1992-07-26 | 8.7 KB | 192 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!mcsun!Germany.EU.net!gmd.de!jvnc.net!darwin.sura.net!mips!mips!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Subject: Re: New C++ type: boole
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
References: <[e-mail]>
Date: Sun, 26 Jul 1992 17:59:44 GMT
Lines: 180

[e-mail] (Doug Moore) writes:

>P. S.  The latest draft of the proposal follows.  Constructive
>feedback is still welcome.  Shall I officialize it and send it off to
>our beloved standards committee?

Um, well, no.
Without intending to insult anyone, I have to say that this proposal has
so many flaws that I don't know where to start. I couldn't be bothered replying
the first time, reasoning that someone was bound to shoot it down soon enough
anyway :-). But before you send it off to the committee, at the very least it
needs some substantial improvements. Oh well, here goes...

>Proposed extension to C++: A Boolean type
>Version 2: 26 Jul 1992
>Doug Moore
>[e-mail]
>
>0. Introduction
>
>One of the weakness of the type system that C++ inherited from C is in
>the overuse of the int type.  In particular, a Boolean type
>representing truth and falsehood does not exist in C, as it does in
>many languages, but instead truth and falsehood are represented by
>integral values 1 and 0.
>
>To some, the weakness of the type system is a strength of the
>language, and expressions like "8 + 5*(a<b)" are part of their
>programming idiom.  No proposed change to C++ can invalidate such
>expressions.        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^
To most of us, that point is enough to convince us that any attempt to
add a boolean type to C++ is not going to buy us enough that it is
worth the effort required to implement it.

>              To many, however, the weakness of the type system that
>permits programming errors to go undetected is a language flaw.  The
>language should provide greater type safety to those who want it.
>Thus, I propose the extension of C++ to define a boolean type.  A
>complete list of amendments to the base document that support the
>extension appears at the end of this document.
>
>1. Outline of the extension.
>
>I propose to add to C++ a new integral type, boole, and literals of
>that type, 0t, and 0f.

0t ??
This is woefully counter-intuitive. If you *have* to have syntactically
special values for true and false, at least make it "1t".
(What's wrong with "boole::false" and "boole::true" or some such?)
C++ is hard enough on beginners already, let's not add yet another
complicated and counter-intuitive syntactic construct.

>Besides paying tribute to a pioneer in the
>formalization of logic, the type name is not one that has been popular
>with those who have tried to simulate boolean types in the past.
>Therefore, that choice of type name is less likely to break current
>code than a type name like "bool" or "Boolean".  The literal names 0t
>and 0f cannot appear, even accidentally, in current code.
>
>The boole type is generated as the result of comparison operations, as
>the result of applying the logical connectives && and ||, and as the
>result of applying the unary operator ! to boole, pointer and
>arithmetic types.  It is used in the first-expression parts of
>conditional expressions (?:), and as the test expressions in if, for,
>while and do statements.  When arithmetic or pointer types appear in a
>context that requires a boolean value, standard logical conversions
>are applied to convert nonzero arithmetic and nonnull pointer types to
>0t.  Warnings can be generated when logical conversions are applied;
>such warnings should be optional early compilers, and later compilers
>should warn by default but optionally disable warnings.
>
>The boole type is an integral type, and in a general arithmetic
>context can be promoted to an integer value 0 or 1.  Integral
>promotion of boole values generates warnings, optionally at first, but
>eventually by default.
>
>2.  New and redefined operators.
>
>Certain operators can be usefully reinterpreted when boole values are
>distinguished from other integral values.  In particular, the unary
>operator ! can be read as isFalse (when applied to booles), as isZero
>(when applied to arithmetic values) and as isNull (when applied to
>pointers).  This proposal does not, therefore, require that warnings
>be issued when ! is applied to various types.  It is hoped that by
>distinguishing the three different meanings of !, confusion about null
>pointers and their representation may be lessened.

So you are going to give me a warning if I write

    if (ptr) ...

but not if I write

    if (!ptr) ...   ?

Sounds very counter-intuitive to me.

>The ++ and -- operators serve a useful, if redundant, purpose in the
>extension.  When applied to boole lvalues, they each invert the
>lvalue.  Thus "b[<expr>] = !b[<expr>]" or, more likely, "b[<expr>] ^=
>1" could be replaced by "++b[<expr>]".  Note that the use of ++ to
>toggle logical values is already a common idiom, particularly in the
>decoding of command line options and the corresponding setting of
>flags.
>
>New operators &&= and ||= extend the op= paradigm, in that they permit
>replacement of, for example, (b1 = b1 && b2) by (b1 &&= b2).  Such
>operators could prove especially useful in a context like (b1[<expr>]
>&& = b2), particularly if <expr> has side effects.  The expression
>could not otherwise be written without the introduction of a temporary
>variable.  Like their underlying logical connectives, these assignment
>operators are short-circuiting; that is, the right hand side need not
>be evaluated if the left hand side determines the result of the
>operation.

Can you stick to proposing one extension at a time, please?
The merit of &&=, ||= is very debateable, as is the idea of introducing
a new idiom ++ for toggling logical values. (Why not just use
"negate(t)" instead of "t++"? The former seems to convey the meaning much
more clearly.)

>3. Additional advantages to the extension.
>
>Among the common errors that will generate warnings when the extension
>is adopted are the confusion of assignment and equality testing (if (a
>= b)) and the confusion that can arise in interval testing (if (a < b
>< c)).  In general, the inadvertant mixture of arithmetic and boolean
>values will be detected and corresponding bugs avoided.
>
>Functions will be overloadable on boolean values, which will be
>convenient for some class designers.  Conversion operators "operator
>boole()", "operator void*()", and "operator int()" will be able to
>simultaneously coexist, which again may convenience some class
>designers.
>
>The primary advantage is probably the resulting elimination of
>progammer defined, conflicting boolean types.  That so many
>programmers choose to simulate a boolean type suggests that it would
>be a popular language feature.  That so many programmers do it
>differently suggests that there is not a clearcut way to do it well
>within the limits of the current language.
>
>4. Disadvantages to the extension.
>
>Programmers who now deliberately overload a function to take an int
>argument, and then call that function with an argument that is of
>boole type under this proposal, will have their programs break.  They
>will have to cast the result argument to int explicitly.
>
>Programs that use the identifier "boole" will break.
>
>The warnings issued for integral promotions of booles and logical
>conversion of arithmetic and pointer types may annoy some.  The
>warnings can be eliminated by explicit casts or, better, by replacing
><boolexpr> by (<boolexpr>?1:0) and <arithexpr> by !!(<arithexpr>)
>where appropriate.

Also you are asking for a lot of work for the compiler-writers.

To me, the advantages seem minimal (or even negative! :-) and do not
justify the disadvantages.

One more comment: what about all the standard library routines?
Are you going to change isdigit() etc. to return booles?
Can you imagine all the conflicts you are going to get, whichever way
you decide to go? I strongly suspect that even if this proposal was
accepted and implemented, programmers would just disable the warnings
rather than bother fixing all their old code. And since most new code
has to at least interface with some old code, they will have to disable
warnings for their new code too, or face heaps of spurious warnings.
(The same thing happened with "const"; however the advantages of using
const where overwhelming, for boole they seem underwhelming :-)

--
Fergus Henderson             [e-mail]
This .signature VIRUS is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!