On Friday, 26 April 2013 at 06:16:29 UTC, deadalnix wrote:
> On Friday, 26 April 2013 at 05:02:50 UTC, Walter Bright wrote:
>> A bool is an integer with the range 0..1
>
> This "feature" never has been useful to me.

+1

On 4/25/2013 11:42 PM, Manipulator wrote:
> What about the implicit conversion for the other types? I could imagine that
> they could cause similar bugs. Why not get rid of the implicit conversion?

Implicit conversions make the menagerie of integer types tractable. Explicit casts are a sledgehammer that often causes bugs rather than eliminates them.

> How about yet another compiler flag?

Compiler flags that alter the meaning of the language are not the solution.

On Friday, 26 April 2013 at 06:42:28 UTC, Manipulator wrote:
> On Friday, 26 April 2013 at 06:18:29 UTC, deadalnix wrote:
>> On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
>>> The real issue is do you want to have the implicit conversions:
>>>
>>> 0 => false
>>> 1 => true
>>>
>>> or would you require a cast?
>>
>> Yes.
>
> +1
>
> What about the implicit conversion for the other types? I could imagine that they could cause similar bugs. Why not get rid of the implicit conversion? How about yet another compiler flag?

No no no no, please no.

On 4/26/2013 12:07 AM, Maxim Fomin wrote:
> Regarding bool type as integer type is C atavism and should be abandoned.

There's a very loooong history of 0 being regarded as false and 1 as true - it goes well beyond C.

> This leads to comic sitatuation presented in the thread when changing literal to
> lvalue or using different enums changes overloading matching.

Yet I showed an analogous example where different overloads were selected based on a different integer value.

There's no getting away from having to pay attention when declaring different overloads of a function. In the original example, the correct solution is to provide a foo(int). I'd be suspicious of any code that only had overloads on just bool and long - it doesn't make sense.

On 4/25/2013 11:16 PM, deadalnix wrote:
> This "feature" never has been useful to me.

It has been useful to me. So there!

> It has caused bug.

The bug is not providing an overload for int.

> Additionally, the behavior is inconsistent :
>
> int i = 1;
> foo(i); // Don't call the bool version.

It is not inconsistent - you forgot a foo(int) overload. '1' is an int. If you don't supply and int overload, it must implicitly convert, and those conversions are considered equivalent.

On Friday, 26 April 2013 at 08:00:28 UTC, Walter Bright wrote:
> On 4/26/2013 12:07 AM, Maxim Fomin wrote:
>> Regarding bool type as integer type is C atavism and should be abandoned.
>
> There's a very loooong history of 0 being regarded as false and 1 as true - it goes well beyond C.

This should be irrelevant in case of long parameter. Such conversion should not be in the language (like feature of array to pointer conversion and function to pointer to function conversion is present in C but not in D).

>> This leads to comic sitatuation presented in the thread when changing literal to
>> lvalue or using different enums changes overloading matching.
>
> Yet I showed an analogous example where different overloads were selected based on a different integer value.
>
> There's no getting away from having to pay attention when declaring different overloads of a function. In the original example, the correct solution is to provide a foo(int). I'd be suspicious of any code that only had overloads on just bool and long - it doesn't make sense.

I argue the correct solution is to call integer function with integer parameter when integer value is passed. Adjusting to buggy compiler behavior isn't a good idea.

On 4/26/2013 1:14 AM, Maxim Fomin wrote:
> I argue the correct solution is to call integer function with integer parameter
> when integer value is passed.

I'm sorry, but that's an assertion not an argument.

The other issue with your assertion, as I explained to Ali, is that D does not have a notion of "better" implicit conversions, and it would be a tragedy to add them.

> Adjusting to buggy compiler behavior isn't a good idea.

It's working as designed - it is not a compiler bug.

On Friday, 26 April 2013 at 08:03:14 UTC, Walter Bright wrote:
> On 4/25/2013 11:16 PM, deadalnix wrote:
>> This "feature" never has been useful to me.
>
> It has been useful to me. So there!
>
>> It has caused bug.
>
> The bug is not providing an overload for int.
>
>> Additionally, the behavior is inconsistent :
>>
>> int i = 1;
>> foo(i); // Don't call the bool version.
>
> It is not inconsistent - you forgot a foo(int) overload. '1' is an int. If you don't supply and int overload, it must implicitly convert, and those conversions are considered equivalent.

Because bool value range should be used as a failover mecanism IMO. And bool shouldn't be considered as an integral.

On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
> On 4/25/2013 10:49 PM, Ali Çehreli wrote:
>> It certainly behaves that way but it isn't an integer type and that's why it is
>> unintuitive.
>
> But it is an integer type.

It is an integral type _internally_.
A bool type should have the values true/false. When someone sees foo(45) he expects it to call an overload that receives an _integral_ value. Which overload is going to be called is a detail (short or long in this example). It is confusing to call an overload that takes bool. Boolean are true/false, not 0, 1 or anything else.

On 04/26/2013 07:02 AM, Walter Bright wrote:
> A bool is an integer with the range 0..1
This is True for the type but for the actual code it looks different. There 0 == false. and everything else is true.

import std.stdio;
void main() {
    if(10) {
        writefln("%d is also true", 10);
   }
}

if(value) proberly becomes:
    cmp value, 0
    jne ifblock

Anyway, I think no implicit casts would be wonderful, sure everybody would hate it at first but than...