bool (was DConf 2019 AGM Livestream)

Isaac S. spam-no-reply-isaac at
Sun May 12 10:27:42 UTC 2019

On Sunday, 12 May 2019 at 05:43:01 UTC, Walter Bright wrote:
> On 5/11/2019 7:27 PM, Mike Franklin wrote:
> I understand. Every programmer, sooner or later, decides to 
> step up and take a swing at inventing boolean. (I have too - 
> did you know that D used to have a `bit` builtin type?)

Yes, D did have a bit type that was removed since it required 
special casing for something that didn't provide much of a 

> The programming landscape is littered with the corpses of one 
> after another.

You say the programming landscape, yet give very limited 
examples. It would help to give examples in languages that did 
not have a hindered boolean type. In languages with a 
non-hindered boolean (e.g. Java) I've only ever seen custom 
booleans for overloading or to flag intent when named arguments 
are unsupported.

> Phobos has multiple ones

Well... yes, this is Phobos; Phobos is in need of a cleanup.

> RefCountedAutoInitialize .yes and .no

Something like this is probably a remnant of code made before 
std.typecons.Flag. It shouldn't have gotten into Phobos 
(regardless of if it was before or after std.typecons.Flag).

> and even a struct Yes and a struct No.

The structs Flag, Yes, and No should not be considered by 
themselves as they are all apart of the same concept. The Flag 
concept is to force a caller to explicitly state what true/false 
mean. This is desired due to the lack of named arguments in D.

> std.bitmanip has an enum A{True,False}. std.json has enum 
> E{True=true}.

In unittests they do. The std.bitmanip is most likely 
overzealously testing something (1-bit sized enum?). The std.json 
one is obviously testing if an enum with an underlying boolean 
value is correctly converted.

> std.typecons has the bizarre enum issue10647_isAlwaysTrue=true;.

Yes, that is bizarre. Considering its a enum constant of type 
bool, this doesn't pertain to custom boolean types.

> The C++ Committee currently is fiercely debating adding a 
> "Boolean" construct in one of the longest threads I've ever 
> seen. One of their problems is it conflicts with the endless 
> "Boolean" types added to existing C++ code, along with every 
> variation "Bool", "Bool", "boolean", etc.
> All this effort strongly implies that there's no such thing as 
> a satisfactory bool type.

No, this implies C++ had a boolean type that was lacking; which 
it *severely* is in type safety.

There are multiple booleans in C++ because programmers are not 
going to unite on one *non-standard* boolean type. Even if the 
committee added one, it will take years for the damage to be 
undone (if ever).

> Will you succeed where 10,000 other programmers have failed?
> Seems unlikely. But I doubt I will dissuade you from trying.

Well other than the overstatement on reinventing the boolean; I 
do agree here that success is unlikely, but not for the same 
reason. A custom boolean type will be used infrequently (I'm 
certainly not depending on a dub package just for a boolean 
type), will have to be imported in *every* file it is used in, 
and will inevitably fracture whenever someone copies the code to 
their codebase.

> So what does work reasonably?
> Treating it like a small integer.

So mixing the concepts of true/false and numerical data is 
"reasonable". I'll have to remember that if I ever have a 
true/false test; 1's and 0's are quicker to write than T's and 

Jokes aside, I have yet to see how making it a "small integer" 
improves this supposed reinventing-the-bool-wheel problem or 
makes it anymore useful than a normal boolean. In fact, it seems 
more-so like you've made a oval wheel: technically functional but 
not really.

> I know the operator ++ difference, and it is my fault that I 
> succumbed to a moment of boolean madness and allowed that in. 
> (++ on D bool is saturation arithmetic, unlike the overflow 
> semantics in every other integer type. It is a mistake, please 
> don't use that as justification for adding more quirky 
> behaviors.)

I don't have to justify other quirky behavior with ++ being 
saturated arithmetic because you said:

> Treating it like a small integer.

If bool is going to be a 1-bit integer with saturated arithmetic 
semantics, then it should act like one. +=, -=, *=, ^^=, /=, and 
%= should be allowed as it is a "small integer". Sure /= and %= 
would largely be a divide-by-zero operation, but at least bool 
would be the type unsafe "integer" it is suppose to be.

> We know what the various integer semantics are, and it fits 
> right in with that.

I have yet to see where bool fits into integer semantics 
reasonably without causing problems and annoyances (as well as 
having just generally weird behavior).

> On a final note, C++ added a std::vector<bool> special case, 
> which works unlike any other vector type. Years of experience 
> have shown that to have been a mistake, just like all the 
> others, and it is widely derided as a complete failure.

That isn't a fault of bool by any means, that is the fault of 
making an unnecessary special case that sometimes acts different 
from every other case.

The real question to look at here is what Nick said:
> Do we have 'bool' because a 1-bit integer is useful, or do we 
> have
> 'bool' because a "true vs false" abstraction is useful?

The answer to that, is because a "true vs false" abstraction is 
useful. A 1-bit integer provides no real benefit: I could still 
use a byte and get pretty much the same behavior (type unsafety 
and all!). I could even do like a lot of C/C++ code I've seen and 
use int.

This is the crux of the argument: *How* does making bool an 
integer add to the language? We have examples of how making bool 
*not* an integer adds to the language, mainly in type safety; we 
still don't have examples of how making it an integer adds to the 

More information about the Digitalmars-d-announce mailing list