> And indeed they do. I did face some very weird bugs caused by that already.

What sort of bugs has it caused for you? Just interested, not questioning whether or not it's a source of bugs.

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.
>

Assembly, PL/I, Algol, ...? Just asking as a language geek.

Personally, given my strong typing background, I dislike the automatic conversion to booleans.

Even my C code has explicit comparisons for NULL pointers, instead of relying in implicit conversions.

--
Paulo

On Friday, 26 April 2013 at 12:34:55 UTC, ixid wrote:
>> And indeed they do. I did face some very weird bugs caused by that already.
>
> What sort of bugs has it caused for you? Just interested, not questioning whether or not it's a source of bugs.

The last time I experienced that feature was with a char getting casted to bool implicitly and then appended to a string, causing super weird behavior after when using the resulting (corrupted) string.

I don't have the actual code as I threw it away (because it was bogous) but took me several hours to figure it out.

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!
>

If you want an int to behave like a bool, then by all means go ahead and write the code yourself, I don't want the compiler to do it for me in a silent manner.

>> It has caused bug.
>
> The bug is not providing an overload for int.
>

That kind of nonintuitive requirement is easily overlooked.

>> 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.

Seriously, let's fix this once and for all. Bool is bool, it's not int and never should have been. I don't understand why we're having this debate.

--rt

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.
>

That is true, but even in theses elder languages, bool is handled as a special case, and not as an regular integral type. For instance, when integral conversion to smaller type is done by applying a mask (or doing a modulo, this is the same thing in this case) it is done by comparing to 0 to compare to bool.

On 04/26/2013 12:03 AM, Maxim Fomin wrote:
> On Friday, 26 April 2013 at 02:13:03 UTC, Ali Çehreli wrote:
>> On 04/25/2013 06:44 PM, Maxim Fomin wrote:
>>
>> > On Thursday, 25 April 2013 at 21:05:43 UTC, Ali Çehreli wrote:
>>
>> > Looks like value range propagation bug because 1 is integer
>> literal and
>> > should be converted to long. There is no way for 1 to be
>> converted to
>> > bool here
>>
>> That special conversion rule of literal 0 and literal 1 being
>> implicitly convertible to false and true gets in the way.
>>
>> > (from TDPL long is below int and it is the shortest way, value
>> > range propagation can work upwards, but the path would be
>> longer).
>> Ali
>
> Sorry but I am not aware of how 1 is converted to bool here.
> True, that 1 is convertible to true,

Yes, through an implicit conversion.

> but here there is function
> with long parameter.

Since the type of literal 1 is int, calling foo(long) would require an implicit conversion as well: from int to long.

In the end, both functions are candidates because they both accept 1 by one implicit conversion.

Ali

On 4/26/2013 6:51 AM, deadalnix wrote:
> The last time I experienced that feature was with a char getting casted to bool
> implicitly and then appended to a string, causing super weird behavior after
> when using the resulting (corrupted) string.


void main()
{
    bool b = 'c';
}

dmd -c foo
foo.d(4): Error: cannot implicitly convert expression ('c') of type char to bool

On 4/26/2013 5:01 AM, Robert Schadek wrote:
> Anyway, I think no implicit casts would be wonderful, sure everybody
> would hate it at first but than...

I've used a language with no implicit casts. It didn't get better, and I have an enduring dislike of it.

On 4/26/2013 7:33 AM, deadalnix wrote:
> 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.
>>
>
> That is true, but even in theses elder languages, bool is handled as a special
> case, and not as an regular integral type. For instance, when integral
> conversion to smaller type is done by applying a mask (or doing a modulo, this
> is the same thing in this case) it is done by comparing to 0 to compare to bool.

I've also spent time with embedded systems that manipulated things by writing out 0's and 1's to ports, designed ABEL (a language for programming PLDs), and simply worked a lot with digital math.

0 and 1 being synonymous with false and true is deeply embedded. A bool is a one bit integer.

I remember once a language that tried to define true and false as something other than 1 and 0. It was horrible.

On Thursday, April 25, 2013 23:01:30 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.

That was one of C's big mistakes. There's nothing whatsoever about bool that makes sense as an integral type. true and false have nothing to do with 1 and 0 or any other integeral values. Having non-boolean values such as 1 and 0 implicitly convert to bool under some set of circumstances can be very useful (which is why cast(bool) is implicitly used in conditions), but in the general case, it just causes bugs.

> The real issue is do you want to have the implicit conversions:
> 
> 0 => false
> 1 => true
> 
> or would you require a cast?

Emphatically yes.

The main place where casting would be annoying - if conditions and loop conditions - already insert an explicit cast underneat the hood. Other cases should require explicit casts; otherwise, we're just going to have bugs as has already been pointed out in this thread and has come up a number of times previously in the newsroup (one of the favorites being "foo" ~ true).

- Jonathan M Davis