Thanks for the feedback, Dave! Responses inline. > On Dec 20, 2017, at 09:23, 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.
There are some ideas listed to prevent this occurence in the proposal. Additionally, such a change may be desirable for a major version release of a library distributed as source. Nothing prevents someone from changing the type of an 'open' method either, but that can also be a breaking change. > • 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. I don't think anyone loves the current name, but we haven't come up with a better one (cf. "Alternatives considered"). Any suggestions? (As mentioned above, I also don't think this is an impossible situation either. But we'd certainly want people to not do it by accident.) > • 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. Swift does not currently support enums with private cases (as mentioned in the proposal), but if it did, such an enum could not be marked "exhaustive". On the C side, there's no way to check that no one's secretly using a private case, so we have to trust the author of the type to use the equivalent annotation responsibly. > 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. This is fair, and we should consider leaving an implicit "default: fatalError()" in even for supposedly exhaustive enums (at least those imported from C). Jordan > > 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
