bool (was DConf 2019 AGM Livestream)

[Nick Sabalausky (Abscissa)]

On 5/12/19 1:43 AM, Walter Bright wrote:
> On 5/11/2019 7:27 PM, Mike Franklin wrote:
>> I think Walter is conflating how bool is stored in memory with its 
>> semantics.
> 
> That's exactly what I'm deliberately doing.
> 
>> I'm currently considering using D's rich modeling features to create a 
>> new boolean type that behaves more like a boolean and less like a 
>> bit.  But it's unfortunate and disappointing we have to resort to 
>> something like that.
> 
> I understand. Every programmer, sooner or later, decides to step up and 
> take a swing at inventing boolean.

No, not really. Only the ones using languages that either lack a 
high-level notion of boolean or conflate it with an integer.

> (I have too - did you know that D 
> used to have a `bit` builtin type?)

Yes. I remember those days. It was renamed "bool" to better reflect its 
actual real-world use-cases.

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

Only in languages that either lack a built-in bool or conflate it with 
integers.

> Phobos has multiple ones 
> - RefCountedAutoInitialize .yes and .no,

Basically the same as the "struct Yes and No" below...(and if it's 
somehow *diffe rent* from the normal struct yes/no, then that sounds 
like a very clear Phobos failing...)

> and even a struct Yes and a 
> struct No.

Which Andrei *intentionally* created as a library-based substitute for 
*named arguments*, if you'll recall without contorting the true history.

> std.bitmanip has an enum A{True,False}. std.json has enum 
> E{True=true}. std.typecons has the bizarre enum 
> issue10647_isAlwaysTrue=true;.
 > (One wonders what would happen if it was
 > set to false. Would it cause a rip in the fabric of space-time? I dare
 > not experiment with that!)


Yet more examples of how D either sucks at bool and/or needs named 
arguments. Thus, completely failing to provide support for the patently 
false "Every programmer, sooner or later, decides to [...] take a swing 
at inventing boolean" claim.

> 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.

Alex, I'll take "Languages which conflate boolean with integer" for 
$500, please...

Daily double!!!!

> All this effort strongly implies that there's no such thing as a 
> satisfactory bool type.

Correction:

All this effort strongly implies that there's no such thing as a 
satisfactory bool type *in languages which conflate booleans with integers*

> 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.

Ohh, I see..So...you're saying that special-casing an *aggregate* of a 
type **cough**char**cough** is bad. And furthermore, that in turn, 
demonstrates that the element type of a special-cased aggregate must 
therefore be unsound as well.

Or is it that applying correct semantics to a type's aggregate without 
also applying them to the type itself is a recipe for disaster?