On Monday, 29 April 2013 at 00:40:08 UTC, Andrei Alexandrescu wrote:
>> 2. Stop allowing implicit bool->int conversions (explicit conversions like in if/while/etc. are of course not included here)
>
> Unlikely to ever happen.

What's the use case against it?

On 4/28/2013 2:05 AM, deadalnix wrote:
> On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
>> On 4/27/2013 2:29 PM, Rob T wrote:
>>> If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords?
>>
>> Because writing cast(bool)0 and cast(bool)1 is unappealing.
>
> VRP say you don't need to.

You're implying there is no need for 1L or 1U either, but there is.

The other reason, mentioned before, is that without making them a keyword or standard type, people will inevitably create their own in one of many different, incompatible, ways.

On Friday, 26 April 2013 at 14:28:59 UTC, Rob T wrote:
> 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!

Come on, characters are not an integral type, they are just an ordered and, for that reason, an indexed type. All the usual operations on characters apply to the index behnid (which is given by the ASCII/Unicode representation).

You are not adding characters, you are adding indices of those characters and so on. And you make a simple convention to always thing "character" for a givent (integer) index, since the index per se is of no much use without its equivalent representation from the ASCII table.

On the same grounds, one could index the values of bool form 4 to 5 and assimilate false for 4 and true for 5, then go with the above convention.

There is a difference, however, between the bool and the char here: for the bool you want to go straight from the logical value to a conventional integral value, do not even think about some kind of tabular representation, while for the ASCII representation of char you seem to forget that such kind of a table exists in the first place.

On Monday, 29 April 2013 at 06:26:44 UTC, Walter Bright wrote:
> On 4/28/2013 2:05 AM, deadalnix wrote:
>> On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
>>> On 4/27/2013 2:29 PM, Rob T wrote:
>>>> If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords?
>>>
>>> Because writing cast(bool)0 and cast(bool)1 is unappealing.
>>
>> VRP say you don't need to.
>
> You're implying there is no need for 1L or 1U either, but there is.
>
> The other reason, mentioned before, is that without making them a keyword or standard type, people will inevitably create their own in one of many different, incompatible, ways.

The same could be said of booleans. If D does not have a proper logical boolean type rather than a "bit" then people will simply write their own (conflicting and likely inefficient) boolean types which work the way they expect.

I've actually used a language where boolean is effectively a 1-bit integer, and I can safely say that I have never found a single advantage over a language with more strongly type booleans which can implicitly be cast to int, but not the other way around. On the other hand the disadvantages are quite extensive: confusion for anyone who has ever used any other high level language, confusing overload resolution as shown in this thread, special cases (booleans convert by comparison rather than truncation, obviously truncation would be stupid but I think this is more of a reason to ditch integer booleans rather than to introduce a special case), different meaning (an integer is a number, a boolean is more like a yes/no enum and that is how it will be used in almost all code regardless of how it is defined in the language), etc.

On Monday, 29 April 2013 at 09:49:59 UTC, Diggory wrote:
> On Monday, 29 April 2013 at 06:26:44 UTC, Walter Bright wrote:
>> On 4/28/2013 2:05 AM, deadalnix wrote:
>>> On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
>>>> On 4/27/2013 2:29 PM, Rob T wrote:
> this thread, special cases (booleans convert by comparison rather than truncation, obviously truncation would be stupid but I think this is more of a reason to ditch integer booleans rather than to introduce a special case), different meaning (an integer is a number, a boolean is more like a yes/no enum and that is how it will be used in almost all code regardless of how it is defined in the language), etc.

gdc:

	bool x = false;
	x++;

main.d:50: Error: operation not allowed on bool 'x'

why not? is just an integer after all. another special case?

this works:

	int x = false;
	x++;

On Sunday, 28 April 2013 at 19:38:26 UTC, eles wrote:
> On Sunday, 28 April 2013 at 19:19:53 UTC, Walter Bright wrote:
>> On 4/27/2013 2:58 PM, jerro wrote:
>>> On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright
>> To reiterate, history amply shows that if 'true' and 'false' are not there, then people will define them themselves, inconsistently, and the end result is not helpful to anybody.
>
>
> So basically, those are to be seen as simple #defines for 0 and 1 and nothing more than that?
>
> I am for a boolean type that is only true and false.
>
> And, if so much needed conversion from int 0 and int non0 to boolean is needed in if() and while(), then simply add ifz(), ifnz(), whilez() and whilenz() to the language.
>
> (that is: ifzero(), infnonzero(), whilezero(), whilenonzero()).
>

This is plain useless as a cast is already inserted here.

On Sunday, 28 April 2013 at 22:40:33 UTC, Andrei Alexandrescu wrote:
> On 4/28/13 5:41 PM, kenji hara wrote:
>> Yes, as Andrei mentioned, it is sometimes useful. But, at least during
>> overload resolution, it must not occur.
>>
>> Kenji Hara
>
> Well the problem has other ramifications beyond bool. Consider:
>
> import std.stdio;
>
> int fun(short v1) { return 1; }
> int fun(long v1) { return 2; }
>
> void main(string[] args)
> {
>     writeln(fun(10_000));
>     writeln(fun(100_000));
> }
>
> This prints "1 2". So the behavior of bool in this case is consistent with the behavior of other integral types.
>

For the same reason, both should call the long overload.

On Monday, 29 April 2013 at 12:30:06 UTC, deadalnix wrote:
> On Sunday, 28 April 2013 at 19:38:26 UTC, eles wrote:
>> On Sunday, 28 April 2013 at 19:19:53 UTC, Walter Bright wrote:
>>> On 4/27/2013 2:58 PM, jerro wrote:
>>>> On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright
> This is plain useless as a cast is already inserted here.

so, only allow explict casting then.

On Monday, 29 April 2013 at 00:45:47 UTC, Mehrdad wrote:
> On Monday, 29 April 2013 at 00:40:08 UTC, Andrei Alexandrescu wrote:
>>> 2. Stop allowing implicit bool->int conversions (explicit conversions like in if/while/etc. are of course not included here)
>>
>> Unlikely to ever happen.
>
> What's the use case against it?

This is useful, and do not cause problem by itself. The reverse conversion is problematic.

> gdc:
>
> bool x = false;
> x++;
>
> main.d:50: Error: operation not allowed on bool 'x'
>
> why not? is just an integer after all. another special case?

If you are going to create a boolean then use it as a boolean - it's not an integer any more. Don't mix and match - there's nothing worse than trying to follow some code that uses a variable in one way then, out of lazyness, uses it in a different way.

>
> this works:
>
> int x = false;
> x++;