digitalmars.D - DIP 1015--removal of integer & character literal conversion to
- Mike Parker (13/13) Sep 14 2018 DIP 1015, "Deprecation and removal of implicit conversion from
- Nicholas Wilson (17/30) Sep 14 2018 Small typo under Breaking Changes and Deprecations
- Mike Franklin (11/45) Sep 15 2018 Thanks! https://github.com/dlang/DIPs/pull/134/files
- Nicholas Wilson (15/34) Sep 15 2018 Its more about dealing with the deprecation warning.
- Steven Schveighoffer (13/21) Sep 16 2018 As precedent, we do have -transition=intpromote, which disables the
- Neia Neutuladh (13/17) Sep 16 2018 And -dip1000. Maybe it would be nice to have a generic
- Steven Schveighoffer (11/29) Sep 15 2018 Looks pretty good to me. The only question I have is on this part:
- Jonathan M Davis (5/34) Sep 15 2018 It would be a serious problem for enums of type bool to change like, and
- Mike Franklin (5/17) Sep 15 2018 You're right, I just tested the implementation, and this is not
- Steven Schveighoffer (3/19) Sep 16 2018 Then I have no objections, looks like a nice positive change to me!
- aliak (14/33) Sep 16 2018 What about:
- Nicholas Wilson (2/10) Sep 16 2018 You have an explicit cast, so no, it would be fine.
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.
Sep 14 2018
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
Sep 14 2018
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:Thanks! https://github.com/dlang/DIPs/pull/134/filesDIP 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!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
Sep 15 2018
On Sunday, 16 September 2018 at 01:47:33 UTC, Mike Franklin wrote:On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas WilsonIts 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.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
Sep 15 2018
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
Sep 16 2018
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.
Sep 16 2018
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/299f81c2352fae4c7fa097de71308d773dcd 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. -Steve
Sep 15 2018
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:It would be a serious problem for enums of type bool to change like, and there should be no need for it. - Jonathan M DavisDIP 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.
Sep 15 2018
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
Sep 15 2018
On 9/15/18 6:29 PM, Mike Franklin wrote:On Saturday, 15 September 2018 at 20:07:06 UTC, Steven Schveighoffer wrote:Then I have no objections, looks like a nice positive change to me! -SteveLooks 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!
Sep 16 2018
On Sunday, 16 September 2018 at 01:29:38 UTC, Mike Franklin wrote:On Saturday, 15 September 2018 at 20:07:06 UTC, Steven Schveighoffer wrote:What about: enum E: bool { no, yes } void main() { E e = cast(E)(0); } Would be illegal I assume? And I think the confusing part about "enum E: bool { yes, no }" is that most people did not catch the bug in the code I just wrote in this sentence. Cheers, - AliLooks 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
Sep 16 2018
On Sunday, 16 September 2018 at 23:59:18 UTC, aliak wrote:What about: enum E: bool { no, yes } void main() { E e = cast(E)(0); } Would be illegal I assume?You have an explicit cast, so no, it would be fine.
Sep 16 2018