<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think there are a couple of different definitions running around, and that is confusing things.<div class=""><br class=""></div><div class="">In my mind, ‘unexpected:’ catches only cases which were unknown at compile time. Adding cases to an enum *should* be a source-breaking change. That is the whole point of this. We should have to update the switch (either by handling new case explicitly, or by adding default) before successfully compiling. What ‘unexpected:’ protects against are changes to a linked binary (e.g. iOS) that are now vending cases we didn’t know about when we were compiled.</div><div class=""><br class=""></div><div class="">I’ll say it again… framing this idea as one of exhaustiveness is really confusing. Enums should just always be exhaustive in swift. There may be cases where we need to use ‘unexpected:’ to handle unexpected/future cases exhaustively. If we annotate an enum as @frozen, then we won’t need to do that to be exhaustive because we know it won’t change out from under us. Always exhaustive. Much less confusing…</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 2, 2018, at 1:41 PM, Xiaodi Wu 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=""><div dir="ltr" class="">On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger <span dir="ltr" class=""><<a href="mailto:swift@nattinger.net" target="_blank" class="">swift@nattinger.net</a>></span> wrote:<br class=""><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" class=""><div class="">[...]</div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">in what other circumstances do we insist that the compiler inform the end user about future additions to the API at compile time?</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">This isn’t a request for the compiler to inform the user about future additions to an API. It is a request to validate the compiler’s knowledge of the<span class="m_1210698447792194873Apple-converted-space"> </span><b class="">current</b> state of an API with the<span class="m_1210698447792194873Apple-converted-space"> </span><b class="">current</b> state of the source code. </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Well, it's of course impossible to inform the user about future additions, so that's poorly phrased on my part. It's about the compiler informing the end user about *new* additions, part of the *current* state of the API, that have cropped up since the user last revised the code when the API was in a *previous* state (or, indistinguishably, members of which a user is unaware regardless of the temporal sequence of when such members were added). In what other circumstances do we insist that the compiler perform this service?</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Enums. That's literally how they work today. You are arguing in favor of actively removing compiler-aided correctness.</div><div class=""><br class=""></div><div class="">There's also protocol requirements</div></div></div></blockquote><div class=""><br class=""></div><div class="">No, that's now how enums work today, and it's not how protocol requirements work today. Enums today are all semantically exhaustive; if a case is added in a later version of a library, it's semantically a *different* enum type that happens to share the same name. Not considering all the cases of an exhaustive enum is an _error_, not a _warning_, because there is no basis on which to proceed. This will not change with the proposal. Likewise, adding a protocol requirement without a default implementation is source-breaking. The result is a compiler _error_.</div><div class=""><br class=""></div><div class="">The question is, what non-source breaking API additions today cause the compiler to inform the end user of such additions? The answer is: none whatsoever. Not new methods or properties on a type, not even new protocol requirements that have a default implementation.</div><div class=""><br class=""></div><div class=""><br class=""></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" class=""><div class=""><div class="">and, arguably, deprecated methods with a proper message ("use foo instead").</div></div></div></blockquote><div class=""><br class=""></div></div><br class=""></div></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=""></div></body></html>