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

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #11 from hsteoh@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.

--

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

Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg@gmail.com

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

--

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

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

--

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

--- Comment #14 from Jonathan M Davis <issues.dlang@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.

--

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

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick@geany.org

--- Comment #15 from Nick Treleaven <nick@geany.org> ---
(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

--

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

Mike <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slavo5150@yahoo.com
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=10560

--

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

Nick Treleaven <nick@geany.org> changed:

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

--

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

--- Comment #16 from Mike Franklin <slavo5150@yahoo.com> ---
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

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #17 from Walter Bright <bugzilla@digitalmars.com> ---
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.

--

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

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilyayaroshenko@gmail.com

--- Comment #18 from Dennis <dkorpel@live.nl> ---
*** Issue 22097 has been marked as a duplicate of this issue. ***

--