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?
