On Friday, 20 May 2022 at 04:34:28 UTC, max haughton wrote:

Yes, it is always better to allow for gradual optimization, going from generic target to increasingly specific as you need it. Case in point, WASM doesn't support SIMD, but the WASM engines (at least one of them) recognizes the output from LLVM builtin simd and reconstruct SIMD for the CPU from sequences of regular WASM instructions. So even if the target does not support SIMD you can get SIMD performance by using "generic" SIMD in the optimizer…

Things are getting much more complicated now for non-real time, just look at the Intel compiler that compiles to a mix of CPU/SIMD/GPU… That's where batch programming is heading…

On 5/19/22 11:27 PM, Walter Bright wrote:

enum A : int { a }

Json j = A.a;
writeln(j); // false

No, it's not. It's a JSON 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.

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.

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.

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.

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

On Friday, 20 May 2022 at 16:02:15 UTC, Steven Schveighoffer wrote:

In fact, it doesn't even require implicit conversion to be removed at all. Matching bool in this case really doesn't make sense, and even by the letter of the spec I'm not sure this is right.

Indeed, one of the constructor in an exact match, while the other is an implicit conversion match.

On Friday, 20 May 2022 at 16:56:50 UTC, deadalnix 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.

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

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.

The way I solved it on my end is to make all the opAssign templates and use specialization, in which case it doesn't go from int to bool.