A builtin Boolean type

[Karl Heuer]

In article <1990Sep7.003709.4853 at laguna.ccsf.caltech.edu> jimmy at tybalt.caltech.edu (Jimmy Hu) writes:
>[I don't want stronger type-checking; I want to be able to write
>"d = (a==b)*c;" and "if (flags & 0x0800)".]

In my other article in alt.lang.cfutures (to which I'm redirecting followups),
I acknowledged the existence of this style of programming.  And of course it
would continue to be legal as long as we're talking about C rather than a
completely new language; there are too many people (and dusty decks) who agree
with you.

My proposal was that the implementation could enable strict typechecking of
Booleans only when <bool.h> is included, so your code would continue to work.
Those of us who use the stricter model will write out the conversions that are
implicit in your example (i.e. "d = (a==b?1:0)*c;" and "if ((flags & 0x0800)
!= 0)", which btw should be just as efficient since that's what the compiler
will probably generate anyway, unless it really has a machine instruction that
compares two integers and sets a register to zero or one instead of setting a
condition code or something) and would use the hypothetical standard <bool.h>,
and get a compiler error rather than the wrong answer when finger slippage
puts the wrong operator in the code (the classic example being "if (a=b)", and
Yes I know that some linters already check for this specific case; I'm just
asking for a more general check).

>But as for the idea of making a standard boolean type for C, I'd have to say
>that this is going a bit too far, since it would make life difficult to the
>many programmers who actually make good use of ints as booleans.

I invoke Heuer's Law: Any feature is a bug unless it can be turned off.  (The
original example, I think, was the way the adm3a terminal would ring the bell
whenever a character was printed in column 72.  On *output*, fergodsake.)  So
leave out <bool.h>, and you continue to get ints.

>Since most languages compile booleans to ints anyways, why not use that
>extra space for your own purposes?

On the other hand, why not let the compiler make use of that space by putting
all the local Boolean objects into a single register?  (Not hard, *if* the
compiler's been told that it's dealing with Boolean rather than integer data!)
Why should I have to do it myself by defining flag bits?

Karl W. Z. Heuer (karl at kelp.ima.isc.com or ima!kelp!karl), The Walking Lint