On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer wrote:
> On 6/20/18 4:16 AM, Mike Parker wrote:
>> [...]
>
> I agree with everything, but one thing that is not specified here is when integers are used as conditionals.
>
> In other words, this still has to compile:
>
> if(1) ...
>
> enum a = 1;
>
> if(a) ...
>
> I can see this somehow getting caught up in the "implicit conversion to bool", so there should be a section to address this.
>
> -Steve

I agree and after reading the DIP I am still confused if we are allowed to write while(1) (and similar conditionals) anymore.

On Thursday, June 21, 2018 18:56:39 Francesco Mecca via Digitalmars-d wrote:
> On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer
>
> wrote:
> > On 6/20/18 4:16 AM, Mike Parker wrote:
> >> [...]
> >
> > I agree with everything, but one thing that is not specified here is when integers are used as conditionals.
> >
> > In other words, this still has to compile:
> >
> > if(1) ...
> >
> > enum a = 1;
> >
> > if(a) ...
> >
> > I can see this somehow getting caught up in the "implicit conversion to bool", so there should be a section to address this.
> >
> > -Steve
>
> I agree and after reading the DIP I am still confused if we are
> allowed to write while(1) (and similar conditionals) anymore.

while(1)

is not technically an implicit conversion. It's an implicit, explicit conversion, which sounds kind of dumb, but it is technically what happens, since when you write a conditional, the compiler inserts an explicit cast. So, when you write something like

if(foo)

it becomes

if(cast(bool)foo)

So, while you don't explicitly put the cast there, semantically, that's what's happening, whereas actual implicit conversions don't use casts. That's why you can do typically stuff like

if(myObject)

but can't do

bool b = myObject;

Any type that can be explicitly cast to bool can therefore be used in a conditional, but only a type with an implicit conversion can be assigned to a bool, passed to a function that accepts bool, or be used in any other situation where an actual bool is required.

So, since the DIP just talks about altering implicit conversions, I think that that it's actually pretty clear that it does not affect conditionals. That being said, it wouldn't be a bad idea to explicitly state in there that it has no effect on code like conditionals where explicit casts are inserted by the compiler.

- Jonathan M Davis

On Wednesday, June 20, 2018 08:16:21 Mike Parker via Digitalmars-d wrote:
> This is the feedback thread for the first round of Community Review for DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool":
>
> https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d8 4/DIPs/DIP1015.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 4, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers.
>
> Please familiarize yourself with the documentation for the Community Review before participating.
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
>
> Thanks in advance to all who participate.

I think that this is a fantastic idea and that experience has shown that on the whole, the implicit conversion to bool causes far more bugs than it fixes and that the annoyance that the extra explicit casts would cause do not outweigh how error-prone it is for most programmers. So, I'm very much behind this.

The only improvement I can think of is what Steven pointed out about conditionals. Technically, conditionals are implicit, explicit casts (in that the compiler inserts an explicit cast for the programmer). So, something like

while(1)

is lowered to

while(cast(bool)1)

and does not actually rely on implicit conversions. That's why something like

if(auto value = key in aa)

works, whereas

bool present = key in aa;

doesn't. However, that's not clear to everyone, and so the DIP should be clear that it does not affect conditionals, since in those cases, the compiler inserts an explicit casts. The DIP just puts integer and character literals in the same boat as something like string literals in that

if("foo")

compiles just fine, whereas

bool b = "foo";

does not.

- Jonathan M Davis

On 6/21/18 3:29 PM, Jonathan M Davis wrote:
> On Thursday, June 21, 2018 18:56:39 Francesco Mecca via Digitalmars-d wrote:
>> On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer
>>
>> wrote:
>>> On 6/20/18 4:16 AM, Mike Parker wrote:
>>>> [...]
>>>
>>> I agree with everything, but one thing that is not specified
>>> here is when integers are used as conditionals.
>>>
>>> In other words, this still has to compile:
>>>
>>> if(1) ...
>>>
>>> enum a = 1;
>>>
>>> if(a) ...
>>>
>>> I can see this somehow getting caught up in the "implicit
>>> conversion to bool", so there should be a section to address
>>> this.
>>>
>>
>> I agree and after reading the DIP I am still confused if we are
>> allowed to write while(1) (and similar conditionals) anymore.
> 
> while(1)
> 
> is not technically an implicit conversion. It's an implicit, explicit
> conversion, which sounds kind of dumb, but it is technically what happens,
> since when you write a conditional, the compiler inserts an explicit cast.

I'm not so sure this is the case for integer literals (literally, I'm not sure). It's certainly the case for custom types. The compiler handles things with builtin types specially. See for instance foreach on ranges vs. arrays.

It might be that this actually is an implicit conversion (it's a literal after all). In that case, what I DON'T want to see after this proposal is accepted is an explanation like "well, why wouldn't you just use while(true)? It's the same thing".

It's why I think the document needs clarification.

-Steve

On Thursday, June 21, 2018 17:23:12 Steven Schveighoffer via Digitalmars-d wrote:
> On 6/21/18 3:29 PM, Jonathan M Davis wrote:
> > On Thursday, June 21, 2018 18:56:39 Francesco Mecca via Digitalmars-d
wrote:
> >> On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer
> >>
> >> wrote:
> >>> On 6/20/18 4:16 AM, Mike Parker wrote:
> >>>> [...]
> >>>
> >>> I agree with everything, but one thing that is not specified here is when integers are used as conditionals.
> >>>
> >>> In other words, this still has to compile:
> >>>
> >>> if(1) ...
> >>>
> >>> enum a = 1;
> >>>
> >>> if(a) ...
> >>>
> >>> I can see this somehow getting caught up in the "implicit conversion to bool", so there should be a section to address this.
> >>
> >> I agree and after reading the DIP I am still confused if we are
> >> allowed to write while(1) (and similar conditionals) anymore.
> >
> > while(1)
> >
> > is not technically an implicit conversion. It's an implicit, explicit conversion, which sounds kind of dumb, but it is technically what happens, since when you write a conditional, the compiler inserts an explicit cast.
> I'm not so sure this is the case for integer literals (literally, I'm not sure). It's certainly the case for custom types. The compiler handles things with builtin types specially. See for instance foreach on ranges vs. arrays.
>
> It might be that this actually is an implicit conversion (it's a literal after all). In that case, what I DON'T want to see after this proposal is accepted is an explanation like "well, why wouldn't you just use while(true)? It's the same thing".
>
> It's why I think the document needs clarification.

In the general case, it has to be an explicit conversion even with literals, because stuff like

while(2)

works. So, I think that it's quite clear that simply getting rid of the implicit conversion of 1 to true can't affect conditionals (though it's certainly possible that the current implementation would run into issues depending on whether the compiler always literally inserts an explicit cast or whether it just does so when it would be required). It simply doesn't make sense that while(1) would fail to work when while(2) continued to work just fine. The semantics of conditionals require that while(1) would continue to work even if the implicit conversion to bool is removed. As such, I think that it's pretty clear what the DIP has to mean if you understand the semantics of conditionals.

But that being said, I agree that the DIP should be clarified. Plenty of folks don't understand conditionals properly and would mistakingly come to the conclusion that this was banning while(1), and there's no reason not to just be explicit about it for the sake of clarity. We don't want folks to be confused about it, and it should be fairly easy to make the DIP clear on the matter.

- Jonathan M Davis

On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer wrote:

> I agree with everything, but one thing that is not specified here is when integers are used as conditionals.
>
> In other words, this still has to compile:
>
> if(1) ...
>
> enum a = 1;
>
> if(a) ...

Although I would prefer it if such code was not allowed without a cast, it is out of scope of this DIP.

I've added a test to the implementation at https://github.com/dlang/dmd/pull/7310/files#diff-d14bf83f29923ca109a2e5315174791a to ensure it doesn't break, and updated the DIP to clarify at https://github.com/dlang/DIPs/pull/127/files.

Thanks for the feedback.

Mike

On Thursday, 21 June 2018 at 17:48:11 UTC, Basile B. wrote:

> The case of `assert(0, "this should not happen");` is not covered. Is this it allowed ?

That will not be affected by this DIP. I've updated the DIP to clarify at
https://github.com/dlang/DIPs/pull/127/files

Thanks for the feedback.

Mike

On 6/22/18 12:33 AM, Mike Franklin wrote:
> On Thursday, 21 June 2018 at 17:11:07 UTC, Steven Schveighoffer wrote:
> 
>> I agree with everything, but one thing that is not specified here is when integers are used as conditionals.
>>
>> In other words, this still has to compile:
>>
>> if(1) ...
>>
>> enum a = 1;
>>
>> if(a) ...
> 
> Although I would prefer it if such code was not allowed without a cast, it is out of scope of this DIP.
> 
> I've added a test to the implementation at https://github.com/dlang/dmd/pull/7310/files#diff-d14bf83f29923ca109a2e5315174791a to ensure it doesn't break, and updated the DIP to clarify at https://github.com/dlang/DIPs/pull/127/files.
> 
> Thanks for the feedback.

Thanks, that looks good. Full support from me!

-Steve

On 2018-06-20 10:16, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for
> DIP 1015, "Deprecation and removal of implicit conversion from integer
> and character literals to bool":

The text says: "Only literals that evaluate to 0 or 1 are affected; all other literals are to remain unchanged" [1]. This goes against example A [2].

[1] https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#description

[2] https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#example-a

-- 
/Jacob Carlborg

On 6/22/18 11:31 AM, Jacob Carlborg wrote:
> On 2018-06-20 10:16, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for
>> DIP 1015, "Deprecation and removal of implicit conversion from integer
>> and character literals to bool":
> 
> The text says: "Only literals that evaluate to 0 or 1 are affected; all other literals are to remain unchanged" [1]. This goes against example A [2].
> 
> [1] https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#description 
> 
> 
> [2] https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md#example-a 
> 
> 

Which literals don't evaluate to 0 or 1 in example A?

Also, example A is just showing what currently compiles, not what is to be affected.

-Steve