On Monday, 12 November 2018 at 17:25:15 UTC, Johannes Loher wrote:
> On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote:
>> Walter and Andrei take the position that this is incorrect the wrong way to view a bool.
>
> Unfortunately you did not include their justification for this position (if any). To me it would be interesting to know about the reasoning that is behind this position.

Everything I know is in the summary at the bottom of the DIP.

On Monday, 12 November 2018 at 17:25:15 UTC, Johannes Loher wrote:
> On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote:
>> Walter and Andrei take the position that this is incorrect the wrong way to view a bool.
>
> Unfortunately you did not include their justification for this position (if any). To me it would be interesting to know about the reasoning that is behind this position.

Maybe you didn't read the link to their reasoning in the DIP, but it's quite simple: they view a bool as an integral type with two possible values, a `bit` if you like. As such, they prefer to fit it into the existing scheme for integral types rather than special-casing booleans as Mike proposed.

On Monday, 12 November 2018 at 17:49:55 UTC, Joakim wrote:
[…]
> it's quite simple: they view a bool as an integral type with two possible values, a `bit` if you like. As such, they prefer to fit it into the existing scheme for integral types rather than special-casing booleans as Mike proposed.

I can’t say I have a strong opinion on this, but possibly it would be right to have an integral “bit” type to differentiate it from the Boolean type, just like we have a “byte” type to differentiate it from “char”...

On 11/12/18 4:45 AM, Mike Parker wrote:
> DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool, has been rejected, primarily on the grounds that it is factually incorrect in treating bool as a type distinct from other integral types.
> 
> The TL;DR is that the DIP is trying to change behavior that is working as intended.
> 
>  From Example A in the DIP:
> 
>      bool b = 1;
> 
> This works because bool is a "small integral" with a range of 0..1. The current behavior is consistent with all other integrals.

But it's not consistent:

void isItAnInteger(T, bool makeCompile = false)() // works for all integers
{
   T val = T.min; // I was surprised these work for bool
   val = T.max;
   static if(!makeCompile)
   {
       long x = -val; // Error: operation not allowed on bool b
       ++val; // Error: operation not allowed on bool val += 1
       val += 1; // same error
   }
   val = cast(T)(T.max + 1);
   assert(val == val.min); // error for bool, true + 1 == 2, but cast(bool)2 truncates to true, not false.
}

void main()
{
    import std.meta;
    static foreach(T; AliasSeq!(int, uint, long, ulong, short, ushort, byte, ubyte))
    {
        isItAnInteger!T();
    }

    // switch second parameter to false to see compiler errors.
    isItAnInteger!(bool, true)();
}

If you have the makeCompile flag set to true, then it asserts for bool, but nothing else.

-Steve

On Monday, 12 November 2018 at 18:25:22 UTC, Bastiaan Veelo wrote:
> I can’t say I have a strong opinion on this, but possibly it would be right to have an integral “bit” type to differentiate it from the Boolean type, just like we have a “byte” type to differentiate it from “char”...

D used to have a `bit` type, waaaay back in the day. It was renamed to `bool` way back in D 0.148, released Feb 25, 2006.

And BTW D 0.149 includes this under the bugs fixed section: "Implicit casts of non-bool to bool disallowed".

What happened since then?

On Mon, 12 Nov 2018 14:10:42 -0500, Steven Schveighoffer wrote:
> But it's not consistent:

And std.traits.isIntegral has not considered bools integral since its initial creation in 2007. Both Walter and Andrei have mucked about with that code and saw no reason to change it, even in wild and lawless days without deprecation cycles or DIPs. Andrei added a doc comment to explicitly note that bools and character types aren't considered integral back in 2009.

On Mon, 12 Nov 2018 09:45:14 +0000, Mike Parker wrote:
>  From Example B in the DIP:
> 
> ```
> int f(bool b) { return 1; }
> int f(int i) { return 2; }
> 
> enum E : int {
>      a = 0,
>      b = 1,
>      c = 2,
> }
> ```
> 
> Here, f(a) and f(b) call the bool overload, while f(c) calls the int
> version. This works because D selects the overload with the tightest
> conversion. This behavior is consistent across all integral types.

enum : int { a = 0 }
enum A : int { a = 0 }
f(a);   // calls the int overload
f(A.a); // calls the bool overload

Tell me more about this "consistency".

On Mon, 12 Nov 2018 20:34:11 +0000, Neia Neutuladh wrote:
> enum : int { a = 0 }
> enum A : int { a = 0 }
> f(a);   // calls the int overload f(A.a); // calls the bool overload
> 
> Tell me more about this "consistency".

Filed issue 19394. (Sorry for spam.)

On 11/12/2018 2:05 AM, Jonathan M Davis wrote:
> *sigh* Well, I guess that's the core issue right there. A lot of us would
> strongly disagree with the idea that bool is an integral type and consider
> code that treats it as such as inviting bugs.

In my college daze I was learning programming alongside designing and building digital circuits, and later software for FPGAs and PLDs (ABEL). The notions of True, T, 1, !0 (from C and Asm), and +5V are all completely interchangeable in my mind.

I once worked with software that defined true as 0 and false as 1, and it was like being in London where all your intuition about cars is wrong. (I'd look to the left when stepping into the street, just to get nearly smacked by a car coming from the right.)

On 11/12/2018 8:28 AM, 12345swordy wrote:
> The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads.

The exact same thing happens when there are both int and short overloads.

The underlying issue is is bool a one bit integer type, or something special? D defines it as a one bit integer type, fitting it into the other integer types using exactly the same rules.

If it is to be a special type with special rules, what about the other integer types? D has a lot of basic types :-)