[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Boris Carvajal  changed:

   What|Removed |Added

 CC||boris...@gmail.com

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Paul Backus  changed:

   What|Removed |Added

 CC||snarwin+bugzi...@gmail.com

--- Comment #23 from Paul Backus  ---
> 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.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

--- Comment #22 from deadalnix  ---
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.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

deadalnix  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #21 from deadalnix  ---
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.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Paul Backus  changed:

   What|Removed |Added

 CC||deadal...@gmail.com

--- Comment #20 from Paul Backus  ---
*** Issue 22240 has been marked as a duplicate of this issue. ***

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

--- Comment #19 from Илья Ярошенко  ---
This bugs causes critical data bugs for various libraries such as
Algebraic/Variant types, JSON and other data libraries. Shame.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Dennis  changed:

   What|Removed |Added

 CC||ilyayaroshe...@gmail.com

--- Comment #18 from Dennis  ---
*** Issue 22097 has been marked as a duplicate of this issue. ***

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #17 from Walter Bright  ---
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 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

--- Comment #16 from Mike Franklin  ---
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

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Nick Treleaven  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17983

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Mike  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=10560

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #15 from Nick Treleaven  ---
(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

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

--- Comment #13 from Denis Shelomovskij verylonglogin@gmail.com ---
(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)`.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

--- Comment #14 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
(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.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

Denis Shelomovskij verylonglogin@gmail.com changed:

   What|Removed |Added

 CC||verylonglogin@gmail.com

--- Comment #12 from Denis Shelomovskij verylonglogin@gmail.com ---
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
}
---

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #11 from hst...@quickfur.ath.cx ---
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.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=


yazan.dab...@gmail.com changed:

   What|Removed |Added

 CC||yazan.dab...@gmail.com


--- Comment #10 from yazan.dab...@gmail.com 2013-07-06 14:27:46 PDT ---
A related issue: http://d.puremagic.com/issues/show_bug.cgi?id=10560

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=



--- Comment #9 from Don clugd...@yahoo.com.au 2013-04-29 01:19:47 PDT ---
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'.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=



--- Comment #7 from Martin Nowak c...@dawg.eu 2013-04-28 04:05:07 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=



--- Comment #8 from Jonathan M Davis jmdavisp...@gmx.com 2013-04-28 06:48:32 
PDT ---
 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=



--- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-04-27 11:24:52 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull


--- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-04-27 11:41:25 PDT ---
https://github.com/D-Programming-Language/dmd/pull/1942

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-04-27 
12:29:50 PDT ---
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'.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=



--- Comment #4 from Kenji Hara k.hara...@gmail.com 2013-04-27 13:23:21 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=


Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 CC||c...@dawg.eu


--- Comment #5 from Martin Nowak c...@dawg.eu 2013-04-27 15:29:18 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2013-04-27 20:43:01 
PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---