<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=""><div class="">It's true that Apple framework authors <i class="">have</i> this capability, known as a "linked-on-or-after check", but it has several caveats:</div><div class=""><br class=""></div><div class="">- It can only check what SDK the <i class="">application</i> was linked against. Any prebuilt libraries that the application uses might have been built against an older or newer SDK. (Yes, Apple discourages linking against libraries you didn't build yourself; at the same time we all know people do it.)</div><div class=""><br class=""></div><div class="">- The check is "what SDK was the application linked against". That means that a developer is opting into all new behavior when they update to a new SDK, instead of just one API's.</div><div class=""><br class=""></div><div class="">- The whole system still has to work together, so it's not always <i class="">possible</i> to preserve the old behavior.</div><div class=""><br class=""></div><div class="">- This means that it's not true that "every library actually keeps old implementations around". What happens is that <i class="">individual</i> frameworks may <i class="">choose</i> to do a "linked-on-or-after" check for a <i class="">particular</i> feature, and modify their behavior based on that. They may also choose not to, which might make sense for, e.g., a new UIView animation kind, or a new property list serialization kind.</div><div class=""><br class=""></div><div class="">I haven't looked at all, but I suspect the vast majority of changes between Apple OS releases, including new cases added to enums, are not guarded by linked-on-or-after checks. (I probably <i class="">can't</i> look, or at least can't tell you, because anything not release-noted might be left that way for a reason.) You may have been thinking of, say, <a href="https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies" class="">the .NET approach to compatibility</a>, where Microsoft actually <i class="">does</i> ship several copies of the standard library and runtimes when they make major breaking changes, but even then they don't do this for every single OS update.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I think Jon's original point has been answered by now: this <i class="">is</i> an issue in Objective-C, but not one that leads to undefined behavior, because in effect the compiler treats all C enums as "non-exhaustive" except in warnings. (You can imagine a `default: break;` inserted at the end of any switch that doesn't otherwise have one in C.)</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 8, 2018, at 11:02, Saagar Jha 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">(Disclaimer: I’m no expert in this, and I know there are people in this list that are, so if there’s anything wrong please feel free to step in and correct me)</div><div class=""><br class=""></div>As far as I’m aware, Apple’s frameworks check which version of the framework you linked with at runtime (for UIKit, I believe this function is UIApplicationLinkedOnOrAfter) and modify their behavior to match. For example, if this function shows your application was linked with the iOS 6 SDK you’d get the old skeuomorphic UI instead of the “flatter”, newer iOS 7-style controls. What this means is every library actually keeps old implementations around in addition to the newer ones and picks the necessary one at runtime, so binary compatibility boils down to things like “don't change the memory layout of classes” rather than “don’t change the behavior of your program”.<div class=""><div class=""><br class=""><div class="">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Saagar Jha</div>
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 5, 2018, at 19:11, Jon Shier 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=""><div class=""></div><div class="">At this point I think it might be useful to outline how binary compatibility works for Objective-C on Apple platforms right now. As an app developer I’m not intimately familiar with what happens when you run an app compiled with the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code paths or something else? The more this thread goes on the more confused I get about why Swift would have this issue while it doesn’t appear to be one for Obj-C. If an enum adds a case now, I don’t have to care until I recompile using the new SDK. Is the intention for Swift to be different in this regard?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon Shier</div><div class=""><br class="">On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2018, at 00:54, Jason Merchant 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=""><div class="">Is it hard to imagine that most everyone can get what they want and keep the syntax clean and streamlined at the same time? Without any "@" signs or other compiler hints?<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">For what it's worth, the original version of the proposal started with a modifier (a context-sensitive keyword, like 'final'), but the core team felt that there were a lot of modifiers in the language already, and this didn't meet the bar.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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"><span style="font-size:12.800000190734863px" class="">"Rather, we are how to enable the vendor of a nonexhaustive enum to add new cases without breaking binaries compiled against previous versions"</span></blockquote><div class=""><br class=""></div><div class="">When an enum changes, and the change causes the code to break, the user can be presented with migration options from an automated IDE tool. In what specific way does this not solve the issue about having to upgrade your code when using someone else's code library? This very notion implies your disgruntled about doing work when things are upgraded, is that really what this fuss is all about?</div><div class=""><br class=""></div><div class="">A well written language interpreter and auto-tooling IDE would not need hints embedded in the code syntax itself. Migration hints from version to version should not be a part of either the past or future version of the code library.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Thanks for bringing this up! Unfortunately, it falls down in practice, because if there's a new enum case, <i class="">it's unclear what you want to do with it.</i> If you're handling errors, it's not obvious that the way you've handled any of the <i class="">other</i> errors is appropriate. In the (admittedly controversial) SKPaymentTransactionState case, none of the existing code would be appropriate to handle the newly-introduced "deferred" case, and nor could StoreKit provide "template" code that would be appropriate to the client app.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In any case, though, the key point on this particular quoted sentence is "without breaking <i class="">binaries"</i>. Any such change must be valid <i class="">without</i> recompilation, and indeed without any intervention from the developer or an IDE, because that's what happens when the user updates their OS.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">...</div><div class=""><br class=""></div><div class="">I don't expect the community to agree on language grammar, but the common sense here on how to achieve the intended goals seems to be out of wack.</div><div class=""><br class=""></div><div class="">If someone can present a clear logical statement as to how an automated migration tool behind the scenes in the IDE to handle all your versioning worries, does not make this whole discussion about adding more convoluted syntax additions irrelevant, I'd love to hear it.</div><div class=""><br class=""></div><div class="">___________________</div><div class=""><br class=""></div><div class="">Sincerely,</div><div class="">Jason</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu <span dir="ltr" class=""><<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>></span> wrote:<br class=""><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="ltr" class=""><span class="">On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><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="ltr" class=""><div class="">I think this whole thing has been unnecessarily convoluted. As a result, the majority of the replies are rabbit holes.</div><div class=""><br class=""></div><div class="">In my opinion, the true root of the concept in question is as follows:</div><div class=""><br class=""></div><div class=""><b class="">A list of something is desired:</b></div><div class="">1 - Pancake</div><div class="">2 - Waffle</div><div class="">3 - Juice</div><div class=""><br class=""></div><div class=""><b class="">Developer wishes to be able to:</b></div><div class=""><b class="">A)</b> Add new things to the list of choices in the future as they come up with new ideas</div><div class=""><b class="">B)</b> Sometimes select one of the choices to be chosen as the normal choice if no choice is made by the user</div><div class=""><br class=""></div><div class="">A and B are <b class="">separate desires</b>. In some circumstances a developer may want to add a new choice and make it the normal choice when there was no normal choice was clarified before.</div></div></blockquote><div class=""><br class=""></div></span><div class="">I don't think this is an accurate summary of the problem being tackled here. Rather, we are how to enable the vendor of a nonexhaustive enum to add new cases without breaking binaries compiled against previous versions. There is little here to do with what a "default" should be. Indeed, it is an explicit design decision of Swift not to support types having an implicit default value.</div><div class=""> </div><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"><span class=""><div dir="ltr" class=""><div class=""></div><div class="">____________________</div><div class=""><br class=""></div><div class=""><b class="">Part 2:</b></div><div class=""><br class=""></div><div class="">After this simple desire is clear, there should be two discussions:</div><div class=""><b class="">A)</b> In a text only coding language, what would we like the syntax to look like? (Without regard to past-bias. What should it really be, forget what mistaken design choices were made in Swift in the past)</div><div class=""><b class="">B)</b> How do we approach making this happen behind the scenes?</div><div class=""><br class=""></div><div class=""><b class="">Bonus:</b> Given that some of us have changed our approach to programming significantly beyond text based coding, and into more dynamic mediums of programming in other niches, and even here and there in Xcode - I would recommend considering how the IDE would show a modern version of this concept. I feel too often that Swift design syntax has a <b class="">lack of awareness between the distinctions of what the IDE should do, as opposed to what the syntax of the language should be</b>, and what should be handled behind the scenes by automated tooling.</div><div class=""><br class=""></div><div class="">_____________________</div><div class=""><br class=""></div><div class=""><b class="">My opinion</b>, in answering the above questions is in preference to a simple easy to read and write syntax, something like the following:</div><div class=""><br class=""></div><div class="">choices Breakfast {</div><div class=""> Pancake, <b class="">Waffle</b>, Juice</div><div class="">}</div><div class=""><br class=""></div><div class="">If a "default" choice is desired, it is obvious to me that I would select the choice from the IDE, and it would be visually indicated that it was the default.</div><div class=""><br class=""></div><div class="">When changes occur, whether new choices are added, old ones are removed or changed, or a default is added, changed, or removed - a behind the scenes automated tool analyzes the changes and presents migration options through the IDE.</div><div class=""><br class=""></div><div class="">_____________________</div><div class=""><br class=""></div><div class="">Sincerely,</div><div class="">Jason</div><div class=""><br class=""></div><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"><br class=""></blockquote></div><br class=""></div></div>
<br class=""></span><span class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></span></blockquote></div><br class=""></div></div>
</blockquote></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></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=""></body></html>