Xref: utzoo comp.lang.c:31713 alt.lang.cfutures:57
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uunet!decwrl!bacchus.pa.dec.com!decvax.dec.com!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c,alt.lang.cfutures
Subject: A builtin Boolean type
Message-ID: <17901@haddock.ima.isc.com>
Date: 9 Sep 90 23:50:09 GMT
References: <5398@harrier.ukc.ac.uk> <3686@goanna.cs.rmit.oz.au> <5409@harrier.ukc.ac.uk> <1990Sep7.003709.4853@laguna.ccsf.caltech.edu>
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Followup-To: alt.lang.cfutures
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 41

In article <1990Sep7.003709.4853@laguna.ccsf.caltech.edu> jimmy@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@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint