I realized further why we should not implement this proposal: It forces the problem of binary compatibility on the app developer, when experience has shown us that problem is better handled by the libraries.
Binary Compatibility “Binary compatibility” is the notion that, even if the libraries you link against change, your app will still behave as it did when it was first compiled. For Swift apps these days, we don’t really have this problem, *yet*. We do have the problem of “binary compatibility” with Apple-provided frameworks, but those are all written in Objective-C, and so the question of “Swift” binary compatibility is still up-in-the-air. Post-ABI stability, we still won’t have much issue with swift binary compatibility on Apple platforms, because there isn’t a mechanism to ship a framework to your users independently of an app update. So from the app POV, none of this will be a problem for Apple platform developers. It will be a problem for non-Apple platform developers. As a simple example, let’s say I write a web app in Swift, and deploy it to a server that has some built-in Swift-on-the-server libraries. Here, my Swift app is decoupled from the libraries, and either one can update independently of each other. If the server owner decides to update from Swift 6 to Swift 6.1, that’s cool. But my web app should continue to run and behave *as if* the server were still running Swift 6, because it has not been re-compiled to use Swift 6.1 features. This is the situation today on Apple platforms. Every app deployed to an Apple device includes a little piece of information in the executable file indicating which SDK was used to compile the app. At runtime, the system frameworks read this value and then alter their behavior accordingly. This is why apps written against the iOS 9 SDK continue to work on iOS 11 devices; UIKit and friends are altering their behavior to provide iOS 9 semantics. This is “binary compatibility”: the binary (your app) continues to be compatible with the dynamically linked frameworks present on the system, even though those frameworks may change. When you have a setup where the frameworks do NOT provide binary compatibility, you end up in DLL Hell [1]. This is the same frustrating scenario when you’re in when you’re doing stuff with homebrew and find that this package you want has multiple dependencies, but these dependencies want different versions of the same library. [2] Exhaustive Enums All of the discussion around exhaustive enums has been from the point-of-view of “what should the behavior be when the libraries change”. Thinking back, I’m actually surprised this is a question at all, because Apple answered this *years* ago: THE BEHAVIOR SHOULD REMAIN UNCHANGED. It is up to the library authors to ensure that they’re doing what the compiled-and-unchanging application is expecting them to do. This discussion around exhaustive enums is basically saying “can we force the developers to deal with binary incompatibility?”. We absolutely should not. There are far more app developers than library developers, and it would be a massively wasteful expenditure of engineering effort to force each and every app developer to deal with binary incompatibility, when the library can do it for them. That is the entire *purpose* of having libraries: abstract out a problem so that I, as an app developer, don’t have to spend the effort to do it myself. Where We Should Go Instead of forcing developers to deal with incompatible libraries, we should be discussing ways to make binary compatibility easier to implement in libraries. One of the major problems I struggled with as a UIKit engineer was the presence of huge numbers of “if … else” checks in the code to deal with binary compatibility. It exploded the cyclomatic complexity of the classes and was a major source of technical debt that I struggled to not add to. I would love to see some sort of formal API versioning that we could do instead in libraries, along with easy runtime support for checking the linked version of libraries, making it easy to strategize implementations based on version, etc. But forcing developers to deal with binary incompatibility is a solution we’ve long known to be a bad one. We should not perpetuate that sin in Swift. Dave [1]: https://en.wikipedia.org/wiki/DLL_Hell <https://en.wikipedia.org/wiki/DLL_Hell> [2]: https://en.wikipedia.org/wiki/Dependency_hell <https://en.wikipedia.org/wiki/Dependency_hell> > On Dec 20, 2017, at 10:23 AM, Dave DeLong via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through >> January 3, 2018. >> >> The proposal is available here: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md> >> When reviewing a proposal, here are some questions to consider: >> >> What is your evaluation of the proposal? >> > A very strong -1. I do not believe this is the appropriate solution to the > problem. > > • While the goal of the proposal is to ensure the correctness of *client* > code, it does nothing to enforce the correctness of evolving *library* code. > As a library author, I can declare a public enum as “exhaustive”, yet still > add a new case in the next release. Nothing in the proposal prevents me from > doing this, yet doing so would obviously break any clients of my library. > > • The name “exhaustive” is misleading for uninformed library authors. An > author creates an enum and then thinks “is that all of the cases? Yep! OK, > it’s @exhaustive”. Then the next evolution of the library occurs, new cases > arise, and now the enum isn’t exhaustive to handle the new cases. So a case > gets added, and the formerly-but-not-actually-exhaustive enum is re-stamped > as exhaustive, because it once again handles all known cases. “Exhaustive” is > not a strong enough name. It does not contain the idea of eternal permanence. > Once an enum gets branded as exhaustive and shipped as such, *it can never > change*. “Exhaustive” does not imply that, and the lack of that implication > will confuse library authors. > > • This proposal does not address the case of “publicly exhaustive enums with > private cases”. Consider NSExpression.ExpressionType: when creating > NSPredicates from format strings, it is easy to create sub-expressions whose > expression types are not one of the publicly listed cases. Based on the > proposal, NSExpression.ExpressionType would be correctly imported as a > non-exhaustive enum. HOWEVER. There is nothing *stopping* a library author > from declaring a publicly exhaustive enum (like NSExpression.ExpressionType), > but having private cases that get leaked (accidentally or not) past the > public barrier and end up in client code. This proposal does nothing to > prevent that. > > The summary of these objections is this: you fundamentally cannot trust > libraries that are not bundled with your application to not change in > unexpected ways. Or in other words, if you don’t have the source code, you > cannot trust it. And even if you do have the source code, it’s still > questionable once you start bridging things in from other languages where > this sort of safety is not enforced. > > To summarize the summary: Leaving a judgement of “exhaustive or not” up to > fallible library authors isn’t safe. > > To summarize the summary of the summary: people are a problem. >> Is the problem being addressed significant enough to warrant a change to >> Swift? >> > Yes, the problem is significant, but in my opinion this is the wrong answer. >> Does this proposal fit well with the feel and direction of Swift? >> > No. Implementing this proposal would give the appearance of safety while > still leaving developers subtly but dangerously vulnerable to imperfectly > written libraries (ie, all of them). >> How much effort did you put into your review? A glance, a quick reading, or >> an in-depth study? >> > I’ve been following the email threads, and I’ve spent years as a library > author, both on Apple frameworks and my own personal libraries. > > Dave > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
