DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", is now ready for Final Review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:

https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review

The current revision of the DIP for this review is located here:

https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9d01/DIPs/DIP1015.md

In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 28 unless I call it off before then.

Thanks in advance for your participation.

On Friday, 14 September 2018 at 13:41:40 UTC, Mike Parker wrote:
> DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", is now ready for Final Review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
>
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
>
> The current revision of the DIP for this review is located here:
>
> https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9d01/DIPs/DIP1015.md
>
> In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 28 unless I call it off before then.
>
> Thanks in advance for your participation.

Small typo under Breaking Changes and Deprecations

"4. After the time period specified in step 4 has elapsed, stage 2 can be merged."

should be

"4. After the time period specified in step _3_ has elapsed, stage 2 can be merged."

The only thing I think is missing is a flag to accelerate the process s.t. the examples

f(E.a);
f(E.b);
g(a - b);

can be made to call their int/long overloads straight away. But otherwise, er, no. A resounding yes with a small request to make the transition faster!

Thanks Mike & Mike! Looking forward to it.

Nic

On 9/14/18 6:41 AM, Mike Parker wrote:
> DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", is now ready for Final Review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
> 
> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
> 
> The current revision of the DIP for this review is located here:
> 
> https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9d01/DIPs/DIP1015.md 
> 
> 
> In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 28 unless I call it off before then.
> 
> Thanks in advance for your participation.

Looks pretty good to me. The only question I have is on this part:

enum YesNo : bool { no, yes } // Existing implementation: OK
                              // After stage 1: Deprecation warning
                              // After stage 2: Error
                              // Remedy: `enum YesNo : bool { no = false, yes = true }`

Why is this necessary? I can't see how there are integer literals being used here, or how implicitly going from `false` to `true` in the 2 items being enumerated is going to be confusing.

-Steve

On Saturday, September 15, 2018 2:07:06 PM MDT Steven Schveighoffer via Digitalmars-d wrote:
> On 9/14/18 6:41 AM, Mike Parker wrote:
> > DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", is now ready for Final Review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
> >
> > https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
> >
> > The current revision of the DIP for this review is located here:
> >
> > https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9 d01/DIPs/DIP1015.md
> >
> >
> > In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 28 unless I call it off before then.
> >
> > Thanks in advance for your participation.
>
> Looks pretty good to me. The only question I have is on this part:
>
> enum YesNo : bool { no, yes } // Existing implementation: OK
>                                // After stage 1: Deprecation warning
>                                // After stage 2: Error
>                                // Remedy: `enum YesNo : bool { no =
> false, yes = true }`
>
> Why is this necessary? I can't see how there are integer literals being used here, or how implicitly going from `false` to `true` in the 2 items being enumerated is going to be confusing.

It would be a serious problem for enums of type bool to change like, and there should be no need for it.

- Jonathan M Davis

On Saturday, 15 September 2018 at 20:07:06 UTC, Steven Schveighoffer wrote:

> Looks pretty good to me. The only question I have is on this part:
>
> enum YesNo : bool { no, yes } // Existing implementation: OK
>                               // After stage 1: Deprecation warning
>                               // After stage 2: Error
>                               // Remedy: `enum YesNo : bool { no = false, yes = true }`
>
> Why is this necessary? I can't see how there are integer literals being used here, or how implicitly going from `false` to `true` in the 2 items being enumerated is going to be confusing.

You're right, I just tested the implementation, and this is not necessary.  I'll remove it.  Thanks!

Mike

On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson wrote:
> On Friday, 14 September 2018 at 13:41:40 UTC, Mike Parker wrote:
>> DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", is now ready for Final Review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage:
>>
>> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
>>
>> The current revision of the DIP for this review is located here:
>>
>> https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9d01/DIPs/DIP1015.md
>>
>> In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 28 unless I call it off before then.
>>
>> Thanks in advance for your participation.
>
> Small typo under Breaking Changes and Deprecations
>
> "4. After the time period specified in step 4 has elapsed, stage 2 can be merged."
>
> should be
>
> "4. After the time period specified in step _3_ has elapsed, stage 2 can be merged."

Thanks! https://github.com/dlang/DIPs/pull/134/files

>
> The only thing I think is missing is a flag to accelerate the process s.t. the examples
>
> f(E.a);
> f(E.b);
> g(a - b);
>
> can be made to call their int/long overloads straight away. But otherwise, er, no. A resounding yes with a small request to make the transition faster!

I'm not too keen on adding a compiler flag, because then I have to worry about deprecating the compiler flag.  I don't know if the bugs that this DIP fixes are serious enough to justify it.  I'd be happy to add it if others are willing to voice their support for it, demonstrating sufficient demand.  Or, I suppose I could add it as an option for Walter and Andrei to approve or reject on judgement day.

Mike

On Sunday, 16 September 2018 at 01:47:33 UTC, Mike Franklin wrote:
> On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson
>> The only thing I think is missing is a flag to accelerate the process s.t. the examples
>>
>> f(E.a);
>> f(E.b);
>> g(a - b);
>>
>> can be made to call their int/long overloads straight away. But otherwise, er, no. A resounding yes with a small request to make the transition faster!
>
> I'm not too keen on adding a compiler flag, because then I have to worry about deprecating the compiler flag.  I don't know if the bugs that this DIP fixes are serious enough to justify it.  I'd be happy to add it if others are willing to voice their support for it, demonstrating sufficient demand.  Or, I suppose I could add it as an option for Walter and Andrei to approve or reject on judgement day.
>
> Mike

Its more about dealing with the deprecation warning.

With the current specification I can tell the compiler I want the old behaviour with a cast. I should be able to tell the compiler that "Yes, I wan't this new behaviour. Please don't warn me about it.", once I have verified that my code is correct under the new behaviour.

Without it, I get a (possibly quite a lot of) deprecation warnings and I have to insert a cast to the corresponding type, e.g. f(cast(int)E.a)/g(cast(long)(a - b)), to verify the behaviour under the new system and silence the deprecation warning (absolutely necessary if using `-de`). Then I have to delete them after stage 2, but what if I want to support older compilers? Well then I have to wait until they are sufficiently old enough.

On 9/15/18 6:29 PM, Mike Franklin wrote:
> On Saturday, 15 September 2018 at 20:07:06 UTC, Steven Schveighoffer wrote:
> 
>> Looks pretty good to me. The only question I have is on this part:
>>
>> enum YesNo : bool { no, yes } // Existing implementation: OK
>>                               // After stage 1: Deprecation warning
>>                               // After stage 2: Error
>>                               // Remedy: `enum YesNo : bool { no = false, yes = true }`
>>
>> Why is this necessary? I can't see how there are integer literals being used here, or how implicitly going from `false` to `true` in the 2 items being enumerated is going to be confusing.
> 
> You're right, I just tested the implementation, and this is not necessary.  I'll remove it.  Thanks!

Then I have no objections, looks like a nice positive change to me!

-Steve

On 9/15/18 8:36 PM, Nicholas Wilson wrote:

> Without it, I get a (possibly quite a lot of) deprecation warnings and I have to insert a cast to the corresponding type, e.g. f(cast(int)E.a)/g(cast(long)(a - b)), to verify the behaviour under the new system and silence the deprecation warning (absolutely necessary if using `-de`). Then I have to delete them after stage 2, but what if I want to support older compilers? Well then I have to wait until they are sufficiently old enough.
> 

As precedent, we do have -transition=intpromote, which disables the requirement for casting smaller integers to int first.

So the way I would expect someone to migrate their project:

1. Examine all deprecations, looking for ones where I actually *WANT* the bool version to be called. Insert cast there.
2. Enable the -transition=nobooldemote or whatever we call it.
3. Once the deprecation period is over, remove the -transition switch.

If I wanted a version to be compilable with older versions of dmd, then I would have to cast.

Hm... another option is to have a switch identify "useless" casts once the deprecation period is over. Or add it into dfix.

-Steve

On Sunday, 16 September 2018 at 17:33:27 UTC, Steven Schveighoffer wrote:
> As precedent, we do have -transition=intpromote, which disables the requirement for casting smaller integers to int first.

And -dip1000. Maybe it would be nice to have a generic -future=[changeid] flag.

I'd like it if these features could be implemented orthogonally enough that we could opt in on a per-module basis and have the same compiler compatible with a much wider range of code. That would be a fair bit of work.

> Hm... another option is to have a switch identify "useless" casts once the deprecation period is over. Or add it into dfix.

Adding it to dfix would be nice, but dfix isn't official or distributed with dmd by default.

Also, dfix uses libdparse internally, which is insufficient for handling this type of analysis. libdparse parses code, but this requires figuring out which overloads would be called.