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
