DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

[H. S. Teoh]

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.