On Wed, Nov 14, 2018 at 06:59:30PM +0000, Carl Sturtivant via Digitalmars-d-announce wrote: > On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote: > > *sigh* Well, I guess that's the core issue right there. A lot of us > > would strongly disagree with the idea that bool is an integral type > > and consider code that treats it as such as inviting bugs. We _want_ > > bool to be considered as being completely distinct from integer > > types. The fact that you can ever pass 0 or 1 to a function that > > accepts bool without a cast is a problem in and of itself.
+1. Honestly, I think 'bool' as understood by Walter & Andrei ought to be renamed to 'bit', i.e., a numerical, rather than logical, value. Of course, that still doesn't address the conceptually awkward behaviour of && and || returning a numerical value rather than a logical true/false state. The crux of the issue is whether we look at it from an implementation POV, or from a conceptual POV. Since there's a trivial 1-to-1 mapping from a logical true/false state to a binary digit, it's tempting to conflate the two, but they are actually two different things. It just so happens that in D, a true/false state is *implemented* as a binary value of 0 or 1. Hence, if you think of it from an implementation POV, it sort of makes sense to treat it as a numerical entity, since after all, at the implementation level it's just a binary digit, a numerical entity. However, if you look at it from a conceptual POV, the mapping true=>1, false=>0 is an arbitrary one, and nothing about the truth values true/false entail an ability to operate on them as numerical values, much less promotion to multi-bit binary numbers like int. I argue that viewing it from an implementation POV is a leaky abstraction, whereas enforcing the distinction of bool from integral types is more encapsulated -- because it hides away the implementation detail that a truth value is implemented as a binary digit. It's a similar situation with char vs. ubyte: if we look at it from an implementation point of view, there is no need for the existence of char at all, since at the implementation level it's not any different from a ubyte. But clearly, it is useful to distinguish between them, since otherwise why would Walter & Andrei have introduced distinct types for them in the first place? The usefulness is that we can define char to be a UTF-8 code unit, with a different .init value, and this distinction lets the compiler catch potentially incorrect usages of the types in user code. (Unfortunately, even here there's a fly in the ointment that char also implicitly converts to int -- again you see the symptoms of viewing things from an implementation POV, and the trouble that results, such as the wrong overload being invoked when you pass a char literal that no-thanks to VRP magically becomes an integral value.) > > But it doesn't really surprise me that Walter doesn't agree on that > > point, since he's never agreed on that point, though I was hoping > > that this DIP was convincing enough, and its failure is certainly > > disappointing. I am also disappointed. One of the reasons I like D so much is its powerful abstraction mechanisms, and the ability of user types to behave (almost) like built-in types. This conflation of bool with its implementation as a binary digit seems to be antithetical to abstraction and encapsulation, and frankly does not leave a good taste in the mouth. (Though I will concede that it's a minor enough point that it wouldn't be grounds for deserting D. But still, it does leave a bad taste in the mouth.) > I'm at a loss to see any significant advantage to having bool as a > part of the language itself if it isn't deliberately isolated from > `integral types`. Same thing with implicit conversion to/from char types and integral types. I understand the historical / legacy reasons behind both cases, but I have to say it's rather disappointing from a modern programming language design point of view. T -- Written on the window of a clothing store: No shirt, no shoes, no service.
