Should you be able to initialize a float with a char?

[Steven Schveighoffer]

On 5/19/22 11:27 PM, Walter Bright wrote:
> On 5/19/2022 5:06 PM, Steven Schveighoffer wrote:
>> I'd happily write that in exchange for not having this happen:
>>
>> ```d
>> enum A : int { a }
>>
>> Json j = A.a;
>> writeln(j); // false
>> ```
> 
> I presume Json is a bool.

No, it's not. It's a [JSON](https://json.org) container. It can accept 
any type on opAssign that is a valid Json type (long, bool, string, 
double, or another Json).

It's actually [this one](https://vibed.org/api/vibe.data.json/Json).

> And the bool is written as false.

The Json is written as false, because calling the overloaded opAssign 
turns into a bool, because bool is an integer, and the enum integer 
value fits in there. It's the compiler picking the bool overload that is 
surprising.

> It implies 
> all implicit conversions should be removed.

No, not at all. bool can implicitly convert to int, char is probably 
fine also (thinking about the OP of this thread, I'm actually coming 
around to realize, it's not that bad). I don't like integers converting 
*to* bool or char (or dchar, etc). That would stop this problem from 
happening. bool being treated as an integral type is suspect.

However, I'm also OK with bool not converting to int implicitly if that 
is necessary for the type system to be sane. Using the trivial `b ? 1 : 
0` conversion is not bad, and the compiler should recognize this pattern 
easily. I don't hold out hope for this to convince you though.

> While that is a reasonable 
> point of view, I used a language that did that (Wirth's Pascal) and 
> found it annoying and unpleasant.

I actually am fine with, even *happy* with, implicit conversions that D 
has, *except* the bool and char implicit conversions *from* integers. 
I've used Swift where implicit conversions are verboten, and it's 
non-stop pain.

> It's clear to me that there is no set of rules that will please everyone 
> and is objectively better than the others. At some point it ceases to be 
> useful to continue to debate it, as no resolution will satisfy everyone.

Of course. There's always a tradeoff. It comes down to, when does the 
language surprise you with a weird thing (like an overloaded function 
that takes bool accepting an int enum because it can fit)? If the choice 
is between those surprises and cast-inconvenience, what is worth more? 
There is no right answer.

-Steve