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. 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.
- Jonathan M Davis
Well, I think the DIP was too narrow in its thinking - by
restricting itself to bool.
There is a bigger picture, which is more important.
Fact 1 - Implicit conversions are nothing more than a weakening
of type safety.
Fact 2 - A weakening of type safety can (and often does)
contribute to bugs.
If anyone wants to dispute facts 1 and 2, please go ahead.
Ideally, a 'modern' programming language would have addressed
these two facts already.
(i.e Rust).
Unfortunately, D is very much tied to its C/C++ heritage, so
'modernizing' can be painful.
D still can still modernize though, without breaking backward
compatibility, by providing 'an option' for the programmer to
explicitly declare their desire for greater type safety - and not
just with bools.
Fact 3 - Everyone will benefit from greater type safety
(disputable - at least for those that prefer convenience
over correctness).
There is just no reason that I can see, why any modern
programming language should allow my bool to be implicitly
converted to a char, int, short, byte, long, double,
float.....and god knows what else...and certainly not without
some warning.
Additionally, it really troubles me to see a programming language
wanting to strut itself on the worlds stage, that can (and worst,
just will) do things like that - no warning, no option to prevent
it.
