<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">This is not what I am saying.<div><br></div><div>Change X helps use case A, but unnecessarily removes feature important (and like argument labels for everything quite Swift defining, but alas...) for use case B.</div><div><br></div><div>What I am saying is that before merging change X we should figure out what is needed (change Y) to ensure that use case B is not harmed while we do also help use case A.</div><div><br></div><div>Use case A being binary frameworks shipped by the OS and use case B being everything else... :).</div><div><br></div><div>Change X being the current proposal.</div><div><br></div><div>Change Y being the feature(s) needed to be added to X to ensure X’ helps use case A without removing the functionality use case B relies on.<br><br><div id="AppleMailSignature">Sent from my iPhone</div><div><br>On 3 Jan 2018, at 02:01, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Tue, Jan 2, 2018 at 7:02 PM, Goffredo Marocchi <span dir="ltr"><<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</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 dir="auto"><span class=""><br><div>On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</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">I think there are a couple of different definitions running around, and that is confusing things.<div><br></div><div>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><br></div><div>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><br></div><div>Thanks,</div><div>Jon</div></div></blockquote><div><br></div><div>I think, then, you fundamentally disagree with the starting premise of the proposal, which is specifically the addition of nonexhaustive enums to the language, and making them the default sort of enum so that adding cases *is not* a source-breaking change. If your whole purpose is to change the proposal so that adding cases will _always_ be a source-breaking change and enums are _never_ nonexhaustive, then I'm not sure how to proceed in the discussion as we're working towards diametrically opposite goals.</div></div></div></div></div></blockquote><div><br></div></span><div>The main issue is a resilience issue and it mainly affects binary frameworks the app links with at runtime and does not package them (read mostly Apple ones for the moment)... the fact that enum changes are source breaking is the whole entire point of swift’s enum and a best practice warning to always have turned on even before with Objective-C. Our goal, and yours goal should be the one and the same too IMHO, is not to throw the proverbial baby out with the bath water.</div><div><br></div><div>We should look for a solution that allows what Apple and OS framework authors need and also what is best for app developers and if we need something to do this we pause this proposal until that something is ready and merged.</div><span class=""><br></span></div></blockquote><div><br></div><div>Hmm, I think indeed we disagree fundamentally on what this proposal is about, or the desired end goal.</div><div><br></div><div>If I understand correctly, *your* end goal is simply to enable something like `@_fixed_layout` for enums, an optimization hint to allow binary frameworks to add cases without being shipped with apps. You want no semantic changes to how enums work.<br></div><div><br></div><div>*My* understand of this proposals goal--and I support it--is that it takes this ABI compatibility problem as a starting point and discovers that there are fundamentally two semantic categories of enums, ones that are necessarily exhaustive (there's either something or nothing for an Optional value, there are three possible comparison results for comparable types, there are four sides to a rectangular window, etc.) and ones that are not. It discovers that, empirically, most enums are nonexhaustive, and proposes changes to the grammar so that Swift distinguishes between these two so as to prompt developers to deal with the issue of nonexhaustiveness where the semantics require it. The goal, then, is to introduce new spellings and semantics to distinguish between two different flavors of enum. Like `open` vs. `public` for classes, this has implications for ABI compatibility but isn't just about ABI compatibility.</div><div><br></div><div>I was laboring under the idea that we were working to make such a wide-ranging change as ergonomic as possible, but it seems like you and Jon do not want such a change at all.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><div><div><blockquote type="cite"><div><div class="m_-7038631873584716845h5"><div>On Jan 2, 2018, at 1:41 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-7038631873584716845m_-5347519832693707137Apple-interchange-newline"></div></div><div><div><div class="m_-7038631873584716845h5"><div dir="ltr">On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger <span dir="ltr"><<a href="mailto:swift@nattinger.net" target="_blank">swift@nattinger.net</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"><div>[...]</div><div><span><br><blockquote type="cite"><div><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"><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"><div><div><span><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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><br></div></span><div>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_-7038631873584716845m_-5347519832693707137m_1210698447792194873Apple-converted-space"> </span><b>current</b> state of an API with the<span class="m_-7038631873584716845m_-5347519832693707137m_1210698447792194873Apple-converted-space"> </span><b>current</b> state of the source code. </div></div></div></div></blockquote><div><br></div><div>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><br></div></span><div>Enums. That's literally how they work today. You are arguing in favor of actively removing compiler-aided correctness.</div><div><br></div><div>There's also protocol requirements</div></div></div></blockquote><div><br></div><div>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><br></div><div>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><br></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"><div><div>and, arguably, deprecated methods with a proper message ("use foo instead").</div></div></div></blockquote><div><br></div></div><br></div></div></div></div><span>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></span></div></blockquote></div><br></div></div>
</div></blockquote></div></body></html>