On Mon, 29 Apr 2013 11:39:27 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/29/2013 10:10 AM, Steven Schveighoffer wrote:
>>
>> I think you are inventing a strawman problem that this bug solves.  There is no
>> need for a "Better" scheme, partial ordering works great, and so do true and false.
>>
>> bool isn't an integer.  It can implicitly cast to an integer, but that's it.
>> Once we implement that rule, everything falls into place.  If you want to pass a
>> "true" boolean literal, use true.  If you want to pass a "false" boolean literal
>> use false.  Using 1 and 0 may be convenient, and may also be valid, but when it
>> matches an integral type as well as bool, then it's ambiguous.
>
> Carefully reading your statement, you are still arguing that matching 1 to long should be "better" than matching it to bool.

Yes, just like it's better matching to long than string.

-Steve

On Tuesday, 30 April 2013 at 14:47:14 UTC, Steven Schveighoffer wrote:
>
> Yes, just like it's better matching to long than string.
>
> -Steve

More precise language is to state that there is no "better match" and long should simply not ever match with bool because long is not the same thing as bool, ie, bool should not be seen as an integral type because it clearly isn't because it does not behave like one and has a completely different purpose in the language otherwise there'd be no need for a bool to have special differences that the other integrals do not have.

How do we get the problem fixed? The sooner it is done the better, otherwise  we'll be forever stuck with subtle bugs and D programmers complaining about it for the rest of eternity.

--rt

On Tue, 30 Apr 2013 10:43:01 -0700, Rob T <alanb@ucora.com> wrote:

> On Tuesday, 30 April 2013 at 14:47:14 UTC, Steven Schveighoffer wrote:
>>
>> Yes, just like it's better matching to long than string.
>>
>> -Steve
>
> More precise language is to state that there is no "better match" and long should simply not ever match with bool because long is not the same thing as bool, ie, bool should not be seen as an integral type because it clearly isn't because it does not behave like one and has a completely different purpose in the language otherwise there'd be no need for a bool to have special differences that the other integrals do not have.
>
> How do we get the problem fixed? The sooner it is done the better, otherwise  we'll be forever stuck with subtle bugs and D programmers complaining about it for the rest of eternity.

1. bool doesn't match to 1 or 0.
2. cast(bool)0 -> false
3. cast(bool)(anything but 0) -> true
4. true -> (implicit cast) 1
5. false -> (implicit cast) 0.

Then all that is left is to change any place where 1 or 0 implicitly casts to true or false to true and false.

The one casualty is any code that passes 1 or 0 to a function overloaded with long, short, or byte (or unsigned versions), and bool, will now silently switch to calling the integral version.  I would posit that this is extremely rare.

-Steve

Am 30.04.2013 20:50, schrieb Steven Schveighoffer:
> On Tue, 30 Apr 2013 10:43:01 -0700, Rob T <alanb@ucora.com> wrote:
>
>> On Tuesday, 30 April 2013 at 14:47:14 UTC, Steven Schveighoffer wrote:
>>>
>>> Yes, just like it's better matching to long than string.
>>>
>>> -Steve
>>
>> More precise language is to state that there is no "better match" and
>> long should simply not ever match with bool because long is not the
>> same thing as bool, ie, bool should not be seen as an integral type
>> because it clearly isn't because it does not behave like one and has a
>> completely different purpose in the language otherwise there'd be no
>> need for a bool to have special differences that the other integrals
>> do not have.
>>
>> How do we get the problem fixed? The sooner it is done the better,
>> otherwise  we'll be forever stuck with subtle bugs and D programmers
>> complaining about it for the rest of eternity.
>
> 1. bool doesn't match to 1 or 0.
> 2. cast(bool)0 -> false
> 3. cast(bool)(anything but 0) -> true
> 4. true -> (implicit cast) 1
> 5. false -> (implicit cast) 0.
>
> Then all that is left is to change any place where 1 or 0 implicitly
> casts to true or false to true and false.
>
> The one casualty is any code that passes 1 or 0 to a function overloaded
> with long, short, or byte (or unsigned versions), and bool, will now
> silently switch to calling the integral version.  I would posit that
> this is extremely rare.
>
> -Steve

+1

+1 (and give a helpful compiler error with suggested modification)

On Monday, 29 April 2013 at 18:39:27 UTC, Walter Bright wrote:
> On 4/29/2013 10:10 AM, Steven Schveighoffer wrote:
>> On Sat, 27 Apr 2013 13:27:39 -0700, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>> .
>> . .
>> bool isn't an integer.  It can implicitly cast to an integer, but that's it.
>> Once we implement that rule, everything falls into place.  If you want to pass a
>> "true" boolean literal, use true.  If you want to pass a "false" boolean literal
>> use false.  Using 1 and 0 may be convenient, and may also be valid, but when it
>> matches an integral type as well as bool, then it's ambiguous.
>
> Carefully reading your statement, you are still arguing that matching 1 to long should be "better" than matching it to bool.


Walter, Don't you agree that the current way can be confusing?

For example, the following code generates 2 differents results/output:

import std.stdio;

void foo(bool b) { writeln("bool"); }
void foo(long l) { writeln("long"); }

void main()
{
long num = 0;

foo(num);
foo(0);
foo(2);
}

output:

long
bool
long

Regardless the fact that num is a variable (long), the first 2 foo calls in my perspective means foo(0), and should generate the same output. Don't you agree with that?