On Sunday, 28 April 2013 at 22:40:33 UTC, Andrei Alexandrescu wrote:
> int fun(short v1) { return 1; }
> int fun(long v1) { return 2; }
> So the behavior of bool in this case is consistent with the behavior of other integral types.


We all understand that, but in that case, it's the programmer's fault (or intention!) for giving different behavior between the two.

In the bool/long case, the programmer is writing perfectly logical code, and it's the compiler that interprets it a weird way.

You can see the difference more clearly here:

	void print(long a, bool newline = false)
	{
	    write(a);
	    if (newline)
	        writeln();
	}

	void print(bool newline = false)
	{
	    if (newline)
	        writeln();
	}
	
	void main()
	{
	    print(1);
	    print(2);
	}


Are you really going to blame the programmer for expecting this to print

	1
	2

or are you going to blame the language for not doing so?

On 04/29/2013 12:51 AM, Mehrdad wrote:
> On Sunday, 28 April 2013 at 22:25:43 UTC, Timon Gehr wrote:
>> On 04/28/2013 11:51 PM, Mehrdad wrote:
>>> On Sunday, 28 April 2013 at 21:29:06 UTC, Timon Gehr wrote:
>>>> On 04/28/2013 10:54 PM, Mehrdad wrote:
>>>>> Isn't that self-contradictory?
>>>
>>>> He is saying bool is an integral type in D. (i.e. it can be promoted
>>>> to 'int' in order to support integer arithmetic.)
>>>
>>> I thought we just established that boolean logic isn't integer logic?
>>
>> Please make sure your statements make sense.
>
>
> Huh?
>
> Walter says bool is an integer,

Certainly not. bool is a type. 2 is an integer.

He says that bool is an integral type (which has a very specific meaning, lined out above.)

> but he understands that boolean variables don't follow integer logic.
>
> That makes no sense, it's like saying "I understand the sky is blue, but
> the sky is red."
>

Check his statements again, I guess.

>
> What part of this is not making sense to you?

Eg. "integer logic".

On Sunday, 28 April 2013 at 23:11:50 UTC, Timon Gehr wrote:
> On 04/29/2013 12:51 AM, Mehrdad wrote:
>> On Sunday, 28 April 2013 at 22:25:43 UTC, Timon Gehr wrote:
>>> On 04/28/2013 11:51 PM, Mehrdad wrote:
>>>> On Sunday, 28 April 2013 at 21:29:06 UTC, Timon Gehr wrote:
>>>>> On 04/28/2013 10:54 PM, Mehrdad wrote:
>>>>>> Isn't that self-contradictory?
>>>>
>>>>> He is saying bool is an integral type in D. (i.e. it can be promoted
>>>>> to 'int' in order to support integer arithmetic.)
>>>>
>>>> I thought we just established that boolean logic isn't integer logic?
>>>
>>> Please make sure your statements make sense.
>>
>>
>> Huh?
>>
>> Walter says bool is an integer,
>
> Certainly not. bool is a type. 2 is an integer.

Sheesh, s/bool/a bool/.


> He says that bool is an integral type (which has a very specific meaning, lined out above.)

o__O why would he waste time commenting on how D _behaves_?
Isn't the whole point of the discussion to figure out how D _should_ behave?


It's not like we haven't understood what the compiler is doing!


> Eg. "integer logic".

Integer logic: 1 + 1 = 2 = 0 (mod 2)
Boolean logic: 1 + 1 = 1 = 1

On 4/28/13 6:47 PM, Minas Mina wrote:
> It's not entirely the same. You provided two overloads of integral
> types. bool is not integral.

Well that's what I was saying - it's consistent in the approach that tries to align bool with a 1-bit integral as much as possible.

Andrei

On 4/28/13 7:19 PM, Mehrdad wrote:
> Integer logic: 1 + 1 = 2 = 0 (mod 2)
> Boolean logic: 1 + 1 = 1 = 1

Well D doesn't implement Boolean operators for + and *. Instead, one would need to use | and & respectively. When + and * are used with bool, promotion to int happens.

I think it's safe to assume D will never implement the Boolean meaning of + and *.


Andrei

On Sunday, 28 April 2013 at 23:37:23 UTC, Andrei Alexandrescu wrote:
> On 4/28/13 7:19 PM, Mehrdad wrote:
>> Integer logic: 1 + 1 = 2 = 0 (mod 2)
>> Boolean logic: 1 + 1 = 1 = 1
>
> Well D doesn't implement Boolean operators for + and *. Instead, one would need to use | and & respectively.When + and * are used with bool, promotion to int happens.
>
> I think it's safe to assume D will never implement the Boolean meaning of + and *.


Sure. But when bool behaves only halfway like an integer (why doesn't it truncate when casting?) and it _also_ will never implement Boolean algebra with + and * (which is fine by me, I never requested that it does) then it should fix _one_ of those two aspects of itself in order to be self-consistent.

We threw out the Boolean algebra fix, so the only choice is to either make it behave entirely like an integer, or to make it be a completely different type.

In other words, we need to either:

1. Make int->bool truncate, or
2. Stop allowing implicit bool->int conversions (explicit conversions like in if/while/etc. are of course not included here)

On Sunday, 28 April 2013 at 23:47:20 UTC, Mehrdad wrote:
> 2. Stop allowing implicit bool->int conversions


And implicit int->bool as well, forgot to mention that.

On Sunday, April 28, 2013 12:16:58 Walter Bright wrote:
> On 4/27/2013 5:53 PM, Jonathan M Davis wrote:
> > which makes it so that you can define how a user-defined type will be treated when used in a condition and for built-in types completely removes if statements and loops from discussions on implicit conversion as there's no implicit conversion being used (unless you're arguing for the cast to not be inserted for conditions, in which case, implicit conversion _would_ be used).
> I can't make heads or tails of this!

I mean that if conditions and loop conditions have nothing to do with implicit conversions, because an explicit cast is inserted for them by the compiler. So, if you're discussing implicit conversions, conditions really have nothing to do with what's being discussed - _unless_ you're arguing that if statements and loops should use an implicit conversion instead of inserting an explicit cast. The poster I was replying to was lumping in examples of if conditions and loop conditions with examples of implicit conversions.

- Jonathan M Davis

On 4/28/13 7:47 PM, Mehrdad wrote:
> In other words, we need to either:
>
> 1. Make int->bool truncate, or

Not going to happen.

> 2. Stop allowing implicit bool->int conversions (explicit conversions
> like in if/while/etc. are of course not included here)

Unlikely to ever happen.

> And implicit int->bool as well, forgot to mention that.

That may have a chance.


Andrie

On 4/28/2013 5:19 PM, Jonathan M Davis wrote:
> I mean that if conditions and loop conditions have nothing to do with implicit
> conversions, because an explicit cast is inserted for them by the compiler.
> So, if you're discussing implicit conversions, conditions really have nothing
> to do with what's being discussed - _unless_ you're arguing that if statements
> and loops should use an implicit conversion instead of inserting an explicit
> cast. The poster I was replying to was lumping in examples of if conditions
> and loop conditions with examples of implicit conversions.

Ok, that's better!