the bit[] type

[bearophile]

jcc7:

> As you can see from the links to newsgroup threads at the bottom of the first
> page, the topic was discussed over many years. Perhaps the discussions have
> tapered off in recent years because the current approach is right.

It's an interesting read, thank you (I was present only at the tail of it).

It's a good example of how even an "obviously simple" feature like a bool/bit type may hide complexities, design difficulties, requires engineering trade-offs, and in the end may produce something with some inevitable design defects.

~bool is forbidden, but in DMD a bool is represented with 8 bits, so it has 255 ways to be true and 1 to be false. A boolean like this:

bool b = void;

May contain something different from 0 or 1, this may cause some surprise.

In those discussions I have seen Walter against the usage of bool as return type for opEquals, because a cast(bool)some_int is equivalent to:
n ? 1 : 0
That requires some instructions, so it isn't fully efficient.

In the pages (operatoroverloading.html and hash-map.html) about the D2 language I have seen different signatures for the struct opEquals, so I may add a little documentation bug report about it:
int opEquals(ref const S s);
const bool opEquals(ref const KeyType s);

P. 258 of TDPL shows a struct opEquals that returns a bool, so I presume the efficiency considerations have left space for a more semantically clean implementation. Isn't DMD able to optimize away (when inlining is present) the slowdown caused by the n?1:0 ?

Bye,
bearophile