<div dir="ltr">On Tue, Dec 19, 2017 at 6:31 PM, Kevin Ballard via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Dec 19, 2017, at 2:58 PM, Ted Kremenek <<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>> wrote:</div><div><div style="word-wrap:break-word;line-break:after-white-space"><blockquote style="margin:15px 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 15px;color:rgb(119,119,119);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><div style="margin:0px"><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0192-non-exhaustive-<wbr>enums.md</a></div></blockquote><span class=""><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><li style="margin:0px"><p style="margin:0px 0px 15px">What is your evaluation of the proposal?</p></li></ul></span></div></div></blockquote></div><div>Overall I like it, but I have some issues.</div><div><br></div><div>I’m not completely sold yet on the idea that public enums should be non-exhaustive by default, as I believe every single public enum I’ve ever written definitely wants to be exhaustive. I’m tempted to say that enums exposed by frameworks that need to maintain future-compatibility (such as Apple’s frameworks) want non-exhaustive by default, but enums exposed by third-party frameworks that follow semantic versioning are likely to want exhaustive by default.</div><div><br></div><div>In fact, this brings to mind another difference between enums in Apple frameworks and enums in third-party Swift frameworks, which is the former is exclusively C-compatible enums whereas the latter is going to have a lot of enums that carry associated values. I have no data to support this but I’m inclined to think that it’s more likely for C-compatible enums to want to be non-exhaustive than it is for enums carrying associated values to want to be non-exhaustive.</div><div><br></div><div>So I guess I’m saying, I want more thought put on the topic of whether enums defined in Swift should actually default to non-exhaustive, and I’m now leaning towards the idea that they should remain exhaustive (but Obj-C enums will still default to non-exhaustive).</div></div></blockquote><div><br></div><div>I think the proposal represents a very good summary of the pros and cons of each approach. At the pre-proposal stage, all possible solutions (there are only three: no default, default to exhaustive, or default to nonexhaustive) were thoroughly explored, and the proposal as revised here represents a thoughtful synthesis of the conversation and has a good justification for the default proposed. I highly doubt that any more back-and-forth on this will surface new arguments not already covered.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div>--</div><div><br></div><div>I don’t like that modules using @testable imports treat all enums as exhaustive. I can see why you want to do that, but being forced to handle non-exhaustive enums in unit tests seems like a valuable guard against accidentally publishing non-exhaustive enums that should be exhaustive.</div></div></blockquote><div><br></div><div>On the contrary, I think that the proposal's behavior for `@testable` is fully consistent and the best solution possible. It preserves the behavior that `@testable` imports are treated as though internal, and it allows for unit tests to have compile-time errors when unexpected cases are added. Any time you want to test nonexhaustive behavior, you can import without `@testable`.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>--</div><div><br></div><div>I’m really not a fan of using a ‘default’ case in non-exhaustive enums. This means that if new cases are added, the compiler can’t help me find my switches. I’d really like to have an alternative way of saying “here’s how to behave in the event of an unknown enum case” without also making that a catch-all for unspecified-but-known cases. You already brought up this issue in the alternatives section, where you stated</div><div><br></div><div><blockquote type="cite">Ultimately I decided not to include this in the proposal with the expectation is that switches over non-exhaustive enums should be uncommon.</blockquote></div><div><br></div><div>But since non-exhaustive enums will be the default, I think this _will_ become quite common, if for no other reason than you’re using a library written by someone who forgot to mark enums as @exhaustive that really should be.</div><div><br></div><div>Regarding the comment that a ‘future’ case is impossible to test, so is a ‘default’ case on a switch that is otherwise exhaustive. In the latter you can test it by commenting out one of your existing cases. But you can do that with ‘future’ too, just by renaming it to ‘default’ first.</div></div></blockquote><div><br></div><div>This, too, I think, has been discussed quite thoroughly, and I think the proposal synthesizes the discussion and presents the best possible solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>In the “Use-side” section it says that a switch without a default case will produce a warning in Swift 4 mode. But in Swift 4 mode all enums are exhaustive by default and the @exhaustive annotation does nothing. These two things can’t both be true or else Swift 4 mode will emit warnings on switches over enums that are very clearly supposed to be exhaustive enums.<br></div></div></blockquote><div><br></div><div>This is curious. I wonder if C enums will be nonexhaustive in both Swift 4 and 5 mode, thereby triggering such warnings. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div><span class=""><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><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></div></blockquote></span><div>Yes</div><span class=""><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><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></div></blockquote></span>Yes<span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><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></div></blockquote></span><div>A quick reading, followed by a few re-readings as I composed this email.</div></div><br><div>-Kevin Ballard</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>