<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><div id="bloop_customfont" style="margin: 0px;">First, this is an extremely well-written proposal, that explains itself well and tries to walk a difficult tightrope. So, A+ for that.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">That said, I think it needs modification before acceptance:</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">* I agree with Dave DeLong that @exhaustive does not actually "do anything", it relies on library authors to do the right thing but library authors cannot be trusted. I am not even sure Optional will continue to have its two cases based on the track record of the swift-evolution process :-P</div><div id="bloop_customfont" style="margin: 0px;">* I agree with Vladimir S that app developers need to be able to use compile-time checks that they handle all the "known cases" for an arbitrary enum (e.g. exhaustive or non-exhaustive), for example with "future" or some other mechanism. Lack of testability does not actually concern me, but I feel it could be addressed by allowing the assignment of Any to a non-exhaustive enum, perhaps gated via a warning or an @testable.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">I feel that a better solution to the underlying dilemma would be the following:</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">* As an app developer, I can use switch! or @import! to mean that I am vendoring this SDK and the runtime library will definitely be the same library I am linking against. So it does not matter if the library author intends to someday add more cases – from my point of of view they are exhaustive, because this is the library I am linking, accept no substitutes. Cases are checked at import time, and there is a runtime exception if somebody swaps the binary for one with "new" cases, may god have mercy on their soul</div><div id="bloop_sign_1514906220646547968" class="bloop_sign">* As an app developer, in the absence of one of those opt-in mechanisms an imported enum is assumed to be open and I must handle either a default case (which is not compile-time checked for exhaustion) or a future case (which is). I prefer "undefined" for "future" as a keyword because it seems to me library authors can also remove cases, regardless of what this proposal says.</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">This solution is a nod to @clattner's "the difference between source packages and binary packages that are updated outside your control (e.g. the OS, or a dynamic library that is updated independently of your app like a 3rd party plugin)." But he is wrong that the difference is somehow tied together with a notion of binary and source: it is a difference between whether the library is vendored or nonvendored, that is whether it is shipped with the application or the OS. If it is shipped with your application, you control the updates and so all enums can be exhaustive, if it is shipped with the OS it is updated independently and who knows what cases will appear at runtime. But there is no law that says I have the sourcecode for all my application's libraries or that OS vendors only ship binaries, so I use "vendored" and "non-vendored", and "import-time" for "compile-time" to be precise in this distinction.</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">As a library author, I am not sure that the @exhaustive promise is meaningful. Unlike resilience more generally where a library author can provide some fallback behavior for client who calls a deprecated method, there is really not much that can be done to support older clients who are unaware of my new enum case. I suppose we could introduce compile-time checks to prevent passing that enum case to an older client, for example</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">public enum Foo {</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"> case old</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"> @introduced (1.1) case new</div><div id="bloop_sign_1514906220646547968" class="bloop_sign">}</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">public final enum Fixed {</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"> case one</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"> @introduced (1.1) case two //error: Can't add a new case to a final enum, drop @introduced or drop final</div><div id="bloop_sign_1514906220646547968" class="bloop_sign">}</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">public func bar() -> Foo {</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"> return .new //error: Not all clients support case new, use if #available or @available</div><div id="bloop_sign_1514906220646547968" class="bloop_sign">}</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">This sort of thing might be a justification for supporting a "final" or "exhaustive" declaration, but the motivation in this listing is to support library authors within their own compilation unit, rather than exposing a signal to app developers that may or may not be reliable moving forward.</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">As shown in this listing, I find "final" more natural and more in the spirit of Swift than @exhaustive.</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div><div id="bloop_sign_1514906220646547968" class="bloop_sign">Drew</div><div id="bloop_sign_1514906220646547968" class="bloop_sign"><br></div></div> <br> <div id="bloop_sign_1514908919628613888" class="bloop_sign"></div> <br><p class="airmail_on">On December 19, 2017 at 4:58:14 PM, Ted Kremenek (<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div></div><div>
<title></title>
<p style="-webkit-print-color-adjust: exact; margin-right: 0px; margin-bottom: 15px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-top: 0px !important;" class="">The review of "SE 0192 - Non-Exhaustive Enums" begins now
and runs through <strong style="-webkit-print-color-adjust: exact;" class="">January 3,
2018</strong>.</p>
<p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">The proposal is available here:</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=""><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></div>
</blockquote>
<p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Reviews are an important part of the Swift evolution
process. All review feedback should be sent to the swift-evolution
mailing list at:</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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div>
</blockquote>
<p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">or, if you would like to keep your feedback private,
directly to the review manager. </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 replying, please try to keep the proposal 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 the proposal
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 the proposal?</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>
<p 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="">Thanks,<br style="-webkit-print-color-adjust: exact;" class="">
Ted Kremenek<br style="-webkit-print-color-adjust: exact;" class="">
Review Manager</p>
_______________________________________________<br>swift-evolution-announce mailing list<br>swift-evolution-announce@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution-announce<br></div></div></span></blockquote></body></html>