Last update September 24, 2010

Boolean Not Equ Bit

Difference (last change) (Author, normal page display)

Changed: 2c2

Note:@#yellow^ Information in this article is outdated. D now has a native bool type, and no longer has a native bit type.

Note:@#yellow^ Information in this article is outdated. D now has a native bool type, and no longer has a native bit type (see

DMD 0.148 in the change log).

Note:

Information in this article is outdated. D now has a native bool type, and no longer has a native bit type (see

DMD 0.148 in the change log).

Table of contents of this page

Background

Discussion

Some Related D Newsgroup Posts

Background

There was a long-lasting debate on the old D Newsgroup (not very surprisingly of a developing language) about the issue of whether the existing bit type really eliminates the need for also having a "true boolean" type. (Historical note: in the development of C++, a similar decades-long debate settled many years ago by adding a native bool type to the language. Nobody really complained afterwards about having bool in the language... )

Note: this is, in some sense, a spectacularly (alarmingly? ) similar thing to not having a "true string" type in the language. Despite the canonical opinion of "we have char[], which (apart from some apparent issues about character indexing with multibyte encoding), does everything a built-in basic string type should do", there is still constant buzz about the missing string type and the request for that pops up almost every week...

To emphasize only one aspect of this debate: if nothing, the opportunity of increasing the expressive power of the language alone should justify adding such basic "extra" features as a bool and a string type. The importance of our ability to express design abstractions, concepts, our ability to map them more directly on language constructs (types) is beyond doubt. If, in this specific case, the language separated, rather than blurred the notions of "machine-level representation type" and "human-level abstract type", that could certainly make almost every designer's life easier.

On the other hand: the language should not have redundant bloat. This is also a very valid concern, even if we do not have agreed definitions of what is redundant and what is bloat. Especially, when bit is almost completely isomorphic to bool -- so why bother? What's more: an "official" bool alias has also been added to the language already, so people of the "Pro-bool" camp can avoid writing bit when they really mean "bool". Now, really why bother?

"bool" alias was added in D 0.69, Aug 11, 2003: "Added bool as an alias for bit."

[About the proper trade-off, let others make their voice heared, too! Someone please add the specific arguments pro/contra! (I just wanted to break the ice here...) -L.K.]

The only problem is that a bit is not a bool . A good paper about this is http://www.python.org/peps/pep-0285.html cited by Mark Evans in my post that you can find below.

List of languages that have a boolean type:

 * Pascal (from the beginning, 1970?)
 * FORTRAN (from FORTRAN 77?)
 * Ada (from the beginning, 1980?)
 * C++ (from the first C++ ISO standard, 199?)
 * Java (from the beginning, 1994)
 * C (from ISO C99 standard)
 * COBOL (from COBOL 2000 standard)
 * C# (from the beginning, 2000?)
 * Python (from version 2.3a0, 2002)
 * Visual Basic 
 * D (from ? )

 -R.M.

How many of those languages have a 'bit' type? or even a bool type which specifically does NOT do int arithmetic. The only thing I see different is that repr(x) or toString(x) is a bit shorter than (x?"True":"False").

-L.C.

Discussion

IMHO there should be a boolean and a string type, if possible as an alias, if necessary as a separate type. My reasoning is that these are semantically different entities (independent of whether they are technically different), that justify to have a representation in the "language" of the programmer. A larger percentage of the programmers will seek and use these abstractions anyway. -- HelmutLeitner

Posts by Walter

DerekParnell writes: Truth and Falsehood are concepts that are not numeric, and thus math operations using them as data should not be allowed. Statements such as "what is the square root of truth" and "if I have three truths and take away a falsehood, what do I have left", do not make sense. However, if you have a computer language that represents these concepts using an numeric datatype, such as int or bit, one can construct valid code statements that implement these nonsense statements above. And that should not really happen.

If one needs to use a boolean datatype as if it had numeric properties, then one should be able to do that by explictly casting it. For example "cast(int)true" could return an integer value of one, and "cast(int)false" could return an integer value of zero.

Also, I see if expressions of the form "if ( <identifer> )" to be syntax shorthands for "if ( <identfier> != 0 )" and thus should still be allowed. -- DerekParnell

I have no issue whatsoever with the choice of "bit" to represent a bool, I think it makes much more sense than using "char" or "int" like C does. (even if bit is harder to implement, when it comes to pointers and such)

But if true and false are D keywords, then I think bool should be too ? Or go back to the dark ages of C99 and remove keywords true and false too: "module std.stdbool; alias bit bool; const bool true=1; const bool false=0;"

That's my main point: the current selection of keywords is inconsistent! -- AndersFBj�rklund