Bug 9999 – Integer literal 0 and 1 should prefer integer type in overload resolution

I think this is unexpected for most of D users, but AFAIK, current compiler implementation (and Walter) intents this behavior. So I honestly mark this as 'enhancement'. Forum discussion: http://forum.dlang.org/thread/[email protected] This program: import std.stdio; void foo(bool b) { writeln("bool"); } void foo(long l) { writeln("long"); } void main() { foo(0); foo(1); foo(2); } Prints: bool bool long Integer literal 0 and 1 prefer 'bool' version than 'long' version.

In here, following mechanism would work for overload resolution. 0. Integer literal 0 and 1 have `int` type, and it does not exactly match to bool and long. 1. bool is regarded as an integer type which has the value 0 or 1. 2. Integer literal 0 and 1 matches to bool with Value Range Propagation (VRP). 3. In general, long values don't match to bool type, but bool values match to long type. So, foo(bool) is more specialized than foo(long) Finally: - foo(0) and foo(1) satisfy all of above conditions, so match to foo(bool). - foo(2) does not satisfy #2, then matches to foo(long). This is a *designed* behavior, but most D users would expect that integer literal value prefers integer overload version. From the user's view, this behavior is *unnatural*. In D, if function arguments match to two or more functions, the ambiguity would be resolved with "partial ordering rule". In above, #3 is corresponding to that. To make the overload resolution mechanism more natural, I think we need to add a special rule there. That is: In partial ordering resolution, bool parameter is treated as less specialized than other integer types (byte, ubyte, short, ushort, int, uint, long, ulong, char, wchar, dchar). The bool literals 'true' and 'false' always don't match to other integer types, so the 'special case' does not affect to other existing overload resolution result IMO.

I do not agree with this enhancement. First off, making special cases for partial ordering takes a simple, straightforward idea and turns it into a potential morass of conflicting cases that we'll be stuck with forever. Secondly, the only issue here is whether '1' should be implicitly convertible to 'bool'.

Walter, I can understand your concern. But I think it would not be so big. Because the possibility of extending basic type set is not so much in the future. Keeping language spec simple is necessary, but also reduce special rule for humans is also important. This is a much rare case that is the mismatch between simple rule and natural behavior for human. Fixing this issue would be valuable for many D users. Logically 'true' and 'false' are not related to any integer values. Although it is widely known and used, considering boolean type as a kind of specialized integer type is not general - it is implementation detail. At least it comes from C language. In old ages, boolean type had not been supported properly in many programming languages, but today, languages which not supporting it would not regarded as useful. D is a modern programming language, so more proper behavior for boolean type is necessary. As one of its goal, D should aim the successor of C. Therefore, we cannot drop the implicit conversion between bool and other integer types which inherited from C. But this problem behavior is definitely unnatural for many programmers, and would enforce to study bad know-how for them. Loosing future users for the compiler simplicity is not good decision. Of course, balance is necessary there, but I think this is necessary complexity.

I can't come up with a use-case for '1' to bool conversion. We already deviate from C++ as there is no implicit integral to bool conversion. bool b = 0; // implicit, questionable bool b = 1; // implicit, questionable bool b = 3; // error bool b = int_val; // error bool b = cast(bool)int_val; // explicit int i = false; // implicit int i = true; // implicit int i = bool_val; // implicit int i = cast(int)bool_val; // explicit The if-condition is handled as explicit cast(bool)expr right? if (0) {} // explicit if (int_val) {} // explicit Now one thing that worries me is that we already had a similar discussion with short/long overloads.

If you simply made it so that integer literals didn't implicitly convert to bool, that would solve this particular problem. There's really no need to have them implicitly convert to bool as that's what true and false are for. But it _would_ mean that integer literals behaved differently from actual integers (though I am firmly in the camp who thinks that integers shouldn't implicitly convert to bool in the first place). Another alternative would be to simply remove bool from Value Range Propagation, as it really doesn't help with bool at all. It _would_ be another special case, but it would be a fairly simple one, and neither of these suggestions require special casing overloads, just implicit conversions of integer literals.

(In reply to comment #6) > If you simply made it so that integer literals didn't implicitly convert to > bool, that would solve this particular problem. There's really no need to have > them implicitly convert to bool as that's what true and false are for. That would solve the problem and I don't see any drawback. > But it _would_ mean that integer literals behaved differently from actual integers > (though I am firmly in the camp who thinks that integers shouldn't implicitly > convert to bool in the first place). > Integers do NOT implicitly convert to bool (see comment 5), but they can be used as http://dlang.org/statement.html#IfCondition which is kind of an explicit cast.

> Integers do NOT implicitly convert to bool (see comment 5) You're right. In the general case, they don't, but VPR makes it so that it can happen (and not necessarily just with literals), whereas if bool were strongly typed, it would _never_ happen. if and loop conditions are a different beast entirely, because they invisibly insert explicit casts, which I don't see as a problem. But I don't think that integral values should ever implicitly convert to bool or vice versa.

I don't have strong feelings about this, but I don't know how to defend the current behaviour. Implicit conversion from int to bool is indeed rather odd. Do we really need it? Initially, literal 0 and 1 sound like acceptable ways of writing 'false' and 'true', but constant folding makes it much harder to justify. foo( 8 - 7 ); // matches bool rather than long! Long ago, D had a 'bit' type which was a 1-bit integer. It was replaced by 'bool'. I think this is an odd case where D still has 'bit' semantics. IE, bool _used to be_ an integer. It isn't any more. Perhaps we didn't go quite far enough in replacing 'bit'.

A related issue: http://d.puremagic.com/issues/show_bug.cgi?id=10560

IMO, we should prohibit implicit conversion from int to bool. The issue is that the mapping 0 -> false, 1 -> true is essentially an arbitrary one. Logically speaking, bool consists of two values, true and false. It's already questionable why they should respectively map to 1 and 0, and even more questionable that this mapping is done *implicitly*. An integer expression should definitely prefer binding to int over bool, even with VRP. If the user actually intended the conversion, that intent ought to be documented with an explicit cast.

Also this issue has to terrible consequences: 1. `f(bool)` is preferred over `f(T)(T)` 2. expressions like `4 - 3` triggers the issue too This code should run fine: --- int f1(bool) { return 1; } int f1(T)(T) { return 2; } void f2()(bool) { static assert(0); } void f2(T)(T) { } void main() { assert(f1( 0) == 2); // fails assert(f1( 1) == 2); // fails assert(f1( 1U) == 2); // fails assert(f1(4 - 3) == 2); // fails f2( 0); // triggers `static assert(0)` f2( 1); // ditto f2( 1U); // ditto f2(4 - 3); // ditto } ---

(In reply to Denis Shelomovskij from comment #12) > Also this issue has to terrible consequences: * two terrible consequences > 1. `f(bool)` is preferred over `f(T)(T)` A workaround is to use `f(T : bool)(T)` specialization instead of `f(bool)`.

(In reply to Denis Shelomovskij from comment #12) > Also this issue has to terrible consequences: > 1. `f(bool)` is preferred over `f(T)(T)` > 2. expressions like `4 - 3` triggers the issue too > > > This code should run fine: > --- > int f1(bool) { return 1; } > int f1(T)(T) { return 2; } > > void f2()(bool) { static assert(0); } > void f2(T)(T) { } > > void main() > { > assert(f1( 0) == 2); // fails > assert(f1( 1) == 2); // fails > assert(f1( 1U) == 2); // fails > assert(f1(4 - 3) == 2); // fails > > f2( 0); // triggers `static assert(0)` > f2( 1); // ditto > f2( 1U); // ditto > f2(4 - 3); // ditto > } > --- That seems pretty bad. It's things like that which make it so that I think that it's usually a bad idea to overload templated and non-templated functions. It's _far_ too easy to have the non-templated one called when you wanted the templated one to be called. > A workaround is to use `f(T : bool)(T)` specialization instead of `f(bool)`. That's also probematic in general, because then stuff like user-defined types which implicitly convert to bool could qualify, and frequently such functions do not take that into account. It can certainly be made to work, and I think that it's great that we can do it, but in general, I think that using implicit conversions in template constraints and specializations is a mistake. If you really want it to take bool though, you can just make the type exact with a template constraint. e.g. void f1(T)(T t) if(is(T == bool)) {} It's ugly that you would have to do that, but it should make it so that the function will only work if it's actually give a bool, which is what you're looking for. Regardless, I think that it's a mistake for VRP to apply to bool. As far as I can tell, it's never of any use, and it's error-prone. IMHO, the fact that foo(1) would call a boolean overload instead of a long overload (which pretty much no one expects) shows that the current behavior is a mistake. And your example is far worse. I suspect that most of us would have run into exactly the same problem and be very surprised by the current behavior.

(In reply to Don from comment #9) > Implicit conversion from int to bool is indeed rather odd. Do we really need > it? Initially, literal 0 and 1 sound like acceptable ways of writing 'false' > and 'true', but constant folding makes it much harder to justify. https://github.com/dlang/dmd/pull/6404

A DIP has been submitted to address this issue: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1015.md A PR implementing the DIP can be found at https://github.com/dlang/dmd/pull/7310

These behaviors in D make sense if one considers a 'bool' to be an integer type that is one bit in size. There are no special conversion rules in D for bool, it behaves just like short, int, long, etc. For example: In the initialization `integral_type x = ct;`, whenever `integral_type` is wide enough to fit constant `ct`, the constant can be used for initialization even though its ostensible type is not the same as `integral_type`. This is a nice successful rule in D, without which we'd need to write nonsense like: ubyte x = cast(ubyte) 100; As for overloading, D chooses the tightest conversion when choosing an overload. This is somewhat surprising, but consistent across bool, ubyte, and all other integral types. Again, there is no special rule for bool. Marking as invalid.

*** Issue 22097 has been marked as a duplicate of this issue. ***

This bugs causes critical data bugs for various libraries such as Algebraic/Variant types, JSON and other data libraries. Shame.

*** Issue 22240 has been marked as a duplicate of this issue. ***

I'm reopening this. Sorry, but to put it bluntly, this behavior is completely retarded. There is no nicer way to put it. This is turning writing a piece of code I'm working on into a total nightmare as integers keeps being converted to bool in weird edge cases.

At the very least, 1 -> true should match as an implicit conversion, not an exact match (in which case, one gets an overload resolution error rather than a bug). That would still be bad, but that would at least not be the opposite one what anyone sensible expects.

> At the very least, 1 -> true should match as an implicit conversion, not an exact match (in which case, one gets an overload resolution error rather than a bug). In this example, both `1 -> long` and `1 -> bool` are implicit conversions, so partial ordering is used, and `1 -> bool` is correctly selected as the more-specialized implicit conversion. The only thing one can really object to here is that the `1 -> bool` conversion is allowed in the first place. But since DIP 1015 has been rejected, it seems like that objection has been overruled, so there is (unfortunately) nothing left to be done here.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18572 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB