<div dir="ltr"><div><span style="font-size:12.8px">I agree with everything said by </span><span style="font-size:12.8px">Brent Royal-Gordon,</span><span style="font-size:12.8px"> however a -1 without the addition of a `future` case or something similar.</span></div><div><ul style="font-size:12.8px;margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif"><li style="margin:0px"><p style="margin:0px 0px 15px">What is your evaluation of the proposal?</p></li></ul><div><font face="Helvetica, arial, sans-serif"><span style="font-size:12.8px">-1, </span></font><span style="font-size:12.8px">this solution solves a real problem but introduces a very significant drawback. It should include a solution that preserves exhaustive pattern matching for the user.</span></div><ul style="font-size:12.8px;margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif"><li style="margin:0px"><p style="margin:0px 0px 15px">Is the problem being addressed significant enough to warrant a change to Swift?</p></li></ul><div><font face="Helvetica, arial, sans-serif"><span style="font-size:12.8px">Yes, absolutely.</span></font></div><ul style="font-size:12.8px;margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif"><li style="margin:0px"><p style="margin:0px 0px 15px">Does this proposal fit well with the feel and direction of Swift?</p></li></ul><div><font face="Helvetica, arial, sans-serif"><span style="font-size:12.8px">Feels like 1 step forward and 1 step back. Solves a real problem and introduces a real new one.</span></font></div><ul style="font-size:12.8px;margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif"><li style="margin:0px"><p style="margin:0px 0px 15px">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</p></li></ul><div><font face="Helvetica, arial, sans-serif"><span style="font-size:12.8px">Rust settled on exhaustive as the default case, signaling the importance of preserving exhaustive pattern matching. I've run into bugs in Objective-C, where there is no exhaustive pattern matching, and that's been a pain - since enums are more powerful in Swift the consequences may be worse.</span></font></div><ul style="font-size:12.8px;margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif"><li style="margin:0px"><p style="margin:0px 0px 15px">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p></li></ul><div><span style="font-size:12.8px">I've actively participated in previous discussions on the topic, and read the proposal top-to-bottom for this review. I leverage enums and exhaustive pattern matching significantly in my own code.</span></div></div><span style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div>> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution <</span><a href="mailto:swift-evolution@swift.org" style="font-size:12.8px">swift-evolution@swift.org</a><span style="font-size:12.8px">> wrote:</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution <</span><a href="mailto:swift-evolution@swift.org" style="font-size:12.8px">swift-evolution@swift.org</a><span style="font-size:12.8px">> wrote:</span><br style="font-size:12.8px"><span style="font-size:12.8px">>></span><br style="font-size:12.8px"><span style="font-size:12.8px">>> • What is your evaluation of the proposal?</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> I am pleased with the broad strokes of this design. I have quibbles with three areas:</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> 1. The `@exhaustive` attribute may be confusing because the term doesn't suggest versioning. My best alternative suggestion is `@frozen`, which matches existing programming terminology: something that has been frozen will not be changed in the future.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> 2. I think we need some kind of `future` keyword in `switch` statements. Even though a nonexhaustive enum may gain additional cases in the future, it's still useful for the compiler to diagnose that you forgot *known* cases.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> You say that "switches over non-exhaustive enums should be uncommon", and this is true for many—perhaps most—non-exhaustive enums, but there is still a large class of non-exhaustive enums which need to be switched over. These are the ones I called "category 2" in my previous email in this thread. `SKPaymentTransactionState` is the example I previously used; others might include `Stream.Status` (if not exhaustive), `CLAuthorizationStatus`, `EKParticipantType`, `PKPaymentMethodType`, and `MKMapType`. Each of these could plausibly have more cases added; each has a good reason why you might switch over cases (such as display in a user interface); and each ought to be promptly updated when a new OS version introduces new cases. Without compiler assistance, those updates won't happen.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> If we plan to add private cases in a future version of Swift, `future` may not be the best keyword. `unknown`, `invalid` (or `case #invalid`), etc. may be better.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> 3. I am very skeptical of treating all enums as exhaustive if imported by `@testable import`. The only reason I can see not to do this is that forcing you to provide `default` might hide tests that need to be updated for new enum cases—but this is the exact problem that `future` is trying to solve. By contrast, treating them as non-exhaustive forces you to actually notice when an enum is published as nonexhaustive and consider whether that's the right approach.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> None of these are showstoppers if left unaddressed, but I think the design would be better if we fixed them.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">>> • Is the problem being addressed significant enough to warrant a change to Swift?</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> Yes. I have no idea how Swift programs currently behave when a future framework version adds a case, but I can't imagine they do anything good.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">>> • Does this proposal fit well with the feel and direction of Swift?</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> Yes, with the exception of conflating `default` and `future`, which removes useful correctness checks.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">>> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> I've experienced bugs in Objective-C caused by the compiler not knowing an enum might have additional, unknown cases. Debugging them sucked.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">>> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> I've participated in multiple rounds of discussion on this topic, and read the proposal top-to-bottom for this review.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> --</span><br style="font-size:12.8px"><span style="font-size:12.8px">> Brent Royal-Gordon</span><br style="font-size:12.8px"><span style="font-size:12.8px">> Architechies</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> ______________________________</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">_________________</span><br style="font-size:12.8px"><span style="font-size:12.8px">> swift-evolution mailing list</span><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><a href="mailto:swift-evolution@swift.org" style="font-size:12.8px">swift-evolution@swift.org</a><br style="font-size:12.8px"><span style="font-size:12.8px">> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" style="font-size:12.8px">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:16px;font-family:Arial;background-color:transparent;font-style:italic;vertical-align:baseline;white-space:pre-wrap">Rex Fenley</span><span style="font-size:16px;font-family:Arial;background-color:transparent;vertical-align:baseline;white-space:pre-wrap"> </span><span style="font-size:11px;font-family:Arial;color:rgb(153,153,153);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">|</span><span style="line-height:1.15;font-family:Arial;color:rgb(153,153,153);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"> </span><span style="font-size:11px;font-family:Arial;color:rgb(153,153,153);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">IOS DEVELOPER</span><br></p></span><span><br><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"><img src="https://lh5.googleusercontent.com/xMgzw3JkFL3DLkdwyq0WxJzKs_XP57gVVCaBMvgi1FKCjSeue0xdx3JZeCWBlxN4KRHhHOfdvJbc1N-AjTwXcKIq4cjJg9H7iaFpQ8WbO4N3c9Y5dzi19cPOs_owPquuqw" width="250px;" height="53px;" style="border: none;"></span></p><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><a href="https://www.remind.com/" style="text-decoration:none" target="_blank"><span style="font-size:11px;font-family:Arial;color:rgb(17,85,204);font-weight:bold;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Remind.com</span></a><span style="font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> </span><span style="font-size:11px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">| </span><a href="http://blog.remind.com/" style="text-decoration:none" target="_blank"><span style="font-size:11px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">BLOG</span></a><span style="font-size:11px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> | </span><a href="https://twitter.com/remindhq" style="text-decoration:none" target="_blank"><span style="font-size:11px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">FOLLOW US</span></a><span style="font-size:11px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> | </span><span style="font-family:Arial;vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> </span><span style="text-decoration:underline;font-size:11px;font-family:Arial;color:rgb(17,85,204);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"><a href="https://www.facebook.com/remindhq" style="text-decoration:none" target="_blank">LIKE US</a></span></p></span></div></div>
</div>