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.

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. Replace bool with ubyte and f(a), f(b) would both call the ubyte version. The same holds for the DIP's Example C.

Walter and Andrei left the door open to change the overload behavior for *all* integral types, with the caveat that it's a huge hurdle for such a DIP to be accepted. It would need a compelling argument.

You can read a few more details in the summary I appended to the DIP:

https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1015.md#formal-assessment

Thanks to Mike Franklin for sticking with the process to the end.

On Monday, November 12, 2018 2:45:14 AM MST Mike Parker via Digitalmars-d- announce 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.

*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. We _want_ bool to be considered as being completely distinct from integer types. The fact that you can ever pass 0 or 1 to a function that accepts bool without a cast is a problem in and of itself. But it doesn't really surprise me that Walter doesn't agree on that point, since he's never agreed on that point, though I was hoping that this DIP was convincing enough, and its failure is certainly disappointing.

- Jonathan M Davis

On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote:
> I was hoping that this DIP was convincing enough, and its failure is certainly disappointing.

Indeed.

On 2018-11-12 10:45, 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.
>
>  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.

Why is that? Is it because "a" and "b" are enum members? I mean, "E" is typed as an int. If I pass an integer literal directly to the function it doesn't behave like that. Example:

import std.stdio;

void foo(int a)
{
    writeln("int");
}

void foo(bool a)
{
    writeln("bool");
}

void main()
{
    foo(0);
    foo(1);
    foo(2);
}

The above example prints "int" three times. The bool overload is not called. Seems like the enum is treated specially.

-- 
/Jacob Carlborg

That's strange, I thought polysemous literals prefer default type, not tightest type.
---
auto b=1;
static assert(is(typeof(b)==bool));
---
Error: static assert:  is(int == bool) is false

On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
> The TL;DR is that the DIP is trying to change behavior that is working as intended.

I thought the whole point of a DIP is to change behavior that is working as intended. Otherwise, we have a bug fix rather than a language change.

On Monday, 12 November 2018 at 15:03:08 UTC, Adam D. Ruppe wrote:
> On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
>> The TL;DR is that the DIP is trying to change behavior that is working as intended.
>
> I thought the whole point of a DIP is to change behavior that is working as intended. Otherwise, we have a bug fix rather than a language change.

+1

On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote:
> On Monday, November 12, 2018 2:45:14 AM MST Mike Parker via Digitalmars-d- announce 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.
>
> *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. We _want_ bool to be considered as being completely distinct from integer types. The fact that you can ever pass 0 or 1 to a function that accepts bool without a cast is a problem in and of itself. But it doesn't really surprise me that Walter doesn't agree on that point, since he's never agreed on that point, though I was hoping that this DIP was convincing enough, and its failure is certainly disappointing.
>
> - Jonathan M Davis

The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. If we have a way of indicating that implicit conversions are not allowed, when passing values to functions then the issues that the DIP brought up is resolved.

- Alex

On Monday, 12 November 2018 at 15:15:17 UTC, M.M. wrote:
> On Monday, 12 November 2018 at 15:03:08 UTC, Adam D. Ruppe wrote:
>> On Monday, 12 November 2018 at 09:45:14 UTC, Mike Parker wrote:
>>> The TL;DR is that the DIP is trying to change behavior that is working as intended.
>>
>> I thought the whole point of a DIP is to change behavior that is working as intended. Otherwise, we have a bug fix rather than a language change.
>
> +1

Let's not get hung up on my apparently poor choice of words for an informal summary in a newsgroup post. The more formal summary I appended to the DIP is closer to what they actually said.

The DIP starts from the assumption that bool should be a distinct type from integrals, a point of view that is not uncommon. Walter and Andrei take the position that this is incorrect the wrong way to view a bool.

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.