Should you be able to initialize a float with a char? (page 8)

On Friday, 20 May 2022 at 16:02:15 UTC, Steven Schveighoffer wrote: > > 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 Actually, there is a right answer. And that's to let the programmer know when this is occuring, if the programmer wants this information (and not requiring the programmer to go look at the assembly!!!). Or, possibly, for the programmer to disable implicit casts, via some annotation -> @noImplicitCasting! I do not like D being like C when it comes to the many unexpected things that can occur due to implicit type casting by the compiler. D needs to be (much) better than C.

On Friday, 20 May 2022 at 22:10:43 UTC, forkit wrote: > I'd like to see an option, for the compiler to output this information, when requested. It does it already for other things (e.g GC). - The location in the file where the cast occurred. - The type being cast from. - The type being cast to. - The result of the cast analysis: upcast, downcast, or mismatch. - Is it an explicit or implicit cast? (i.e. the programmer did it, or the compiler did it)

May 20, 2022

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

Posted by Paul Backus
in reply to deadalnix

Permalink

Paul Backus

Posted in reply to deadalnix

Permalink

On Friday, 20 May 2022 at 18:41:39 UTC, deadalnix wrote:

On Friday, 20 May 2022 at 17:15:07 UTC, Paul Backus wrote:

In this example, both int and bool are implicit conversions, because the type of E.a is E, not int. So partial ordering is used to disambiguate, and the compiler (correctly) determines that the bool overload is more specialized than the int overload, because you can pass a bool argument to an int parameter but not the other way around.

As soon as you allow the E -> bool implicit conversion (via VRP), everything else follows.

Fair enough, because of the enum. You probably don't want to cast do bool via VRP.

But it also happens with integer literals, so clearly there is a problem.

It happens with literals only if the literal type is not an exact match for the parameter type:

import std.stdio;

void fun(int) { writeln("int"); }
void fun(bool) { writeln("bool"); }

void main()
{
    fun(int(0)); // int (exact match)
    fun(ubyte(0)); // bool (implicit conversion)
}

So, this case is exactly the same as the enum case. Once you allow the implicit conversion to bool, everything else follows from the normal language rules.

Forums