<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 19, 2017, at 20:15, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><blockquote class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); padding: 0px 15px;"><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;">As an aside: there seems to be increasingly comments about proposals that say:</div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><br class=""></div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"> 1. This was discussed at the evaluation stage and rejected. </div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"> 2. This is how it is implemented in the patch.</div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><br class=""></div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;">And other comments along those lines. Neither the pre-proposal discussions nor the proposed implementation are intended to limit the scope of the review. Therefore I don’t think people should raise this as reasons. You should remember that the process is deliberately staged this way and different people may well be commenting (in fact the process rather assumes that people in the formal review will be a wider set of people). </div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><br class=""></div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;">Anyway gripe over. </div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md</a></span></div></blockquote><ul class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;"><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">What is your evaluation of</span><span style="background-color: rgba(255, 255, 255, 0);" class=""> </span><a href="x-apple-data-detectors://7" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="misc" x-apple-data-detectors-result="7" style="background-color: rgba(255, 255, 255, 0); -webkit-text-decoration-color: rgba(0, 0, 0, 0.258824);" class="">the proposal</a><span style="background-color: rgba(255, 255, 255, 0);" class="">?</span></p><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">+1/2</span></p><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">I only give this a half because whilst it is important I can see three issues:</span></p><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class=""> 1. It doesn’t seem very Swift like to have a different rule, default non-exhaustive, for public as opposed to non-public. </span></p></li></ul></div></div></blockquote><div>I guess people are still misunderstanding this. Within a module, switches must still be exhaustive, always, because the switch can never get out of sync with the enum definition. The "exhaustive" annotation only applies to clients across module boundaries.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><ul class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;"><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class=""> 2. It doesn’t seem very Swift like to have the default the unsafe case. </span></p></li></ul></div></div></blockquote><div>I find it interesting that you call this the "unsafe" case. <a href="https://imgur.com/4OWRavD" class="">From my point of view</a>, it is very much in line with Swift's current design to have the default be "force clients to consider all possibilities" (like Optional), as well as "let library authors decide what a client should be able to rely on" (like 'open').</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><ul class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;"><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class=""> 3. Other languages have better solutions - see below under other languages</span></p></li><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">Is the problem being addressed significant enough to warrant a change to Swift?</span></p><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">Yes, Swift ABI compatibility going forwards is important</span></p></li><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">Does this proposal fit well with the feel and direction of Swift?</span></p><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">No. As mentioned above different rules for public and a non-safe default don’t see that Swift like. </span></p></li><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></p><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">Both Java and Scala have a better solution. In these languages enums (Scala calls them case classes) can implement protocols and the user of an enum rarely writes a switch statement, instead they call protocol methods. Enums in these languages are a fixed set of derived classes; i.e. normal OO programming rather than functional programming, which works well in the case of wanting to expand later the number of enum cases. </span></p></li></ul></div></div></blockquote><div>This is an interesting point that I probably should have expanded more in the "comparison with other languages" section. Swift has protocols too, and you can build most of the features of enums with protocols. (Set aside the inferior pattern-matching for now; that's something we could add to Swift.) This is currently much more heavyweight than enums, but let's roll with it.</div><div><br class=""></div><div>Next we have to deal with C enums, which can have "private cases" or newly-added cases. Okay, maybe those get imported as structs instead, like NS_OPTIONS. That's not too bad, is it?</div><div><br class=""></div><div>Now we're back in a place where 'enum' always means "exhaustive". That's good, right? Except…now we have a kind of type where the recommendation will be "don't use these in your library's public API; they'll be stuck that way forever", a trap waiting for library authors. That's a problem C has with structs, and it's something we don't want to bring into Swift. Making a library necessarily requires more care than making an app, but we don't want there to be techniques that <i class="">only</i> make sense within a module, and are <i class="">discouraged</i> when writing a library.</div><div><br class=""></div><div>So we can implement this world in Swift. I just don't think it'll be a better one. When someone makes a library, the default should be safe <i class="">for them.</i> That means that they reserve the ability to add cases, and <i class="">also</i> to make the enum "exhaustive" in the future if it turns out that's the right thing to do.</div><div><br class=""></div><div>(You're free to continue to disagree with me on this; thanks for getting me to write it out.)</div><div><br class=""></div><div>Jordan</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><ul class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px;"><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;"><span style="background-color: rgba(255, 255, 255, 0);" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span></p><div class="">Have followed the discussions. Used enums in Swift and other languages extensively. </div></li></ul><br class=""><div class="">-- Howard.</div><div class=""><br class="">On 19 Dec 2017, at 12:58 pm, Ted Kremenek <<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">When replying, please try to keep <span class="">the proposal</span> link at the top of the message:</p><blockquote style="-webkit-print-color-adjust: exact; 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);" class=""><div style="-webkit-print-color-adjust: exact; margin: 0px;" class="">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md</a><br style="-webkit-print-color-adjust: exact;" class="">...<br style="-webkit-print-color-adjust: exact;" class="">Reply text<br style="-webkit-print-color-adjust: exact;" class="">...<br style="-webkit-print-color-adjust: exact;" class="">Other replies</div></blockquote><h3 id="toc_0" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 18px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">What goes into a review of a proposal?</h3><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">The goal of the review process is to improve <span class="">the proposal</span> under review through constructive criticism and, eventually, determine the direction of Swift. </p><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">When reviewing a proposal, here are some questions to consider:</p><ul style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class=""><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">What is your evaluation of <span class="">the proposal</span>?</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">Does this proposal fit well with the feel and direction of Swift?</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</p></li><li style="-webkit-print-color-adjust: exact; margin: 0px;" class=""><p style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p></li></ul><div style="-webkit-print-color-adjust: exact; margin-top: 15px; margin-right: 0px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-bottom: 0px !important;" class=""><br class="webkit-block-placeholder"></div></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>