> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > <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? > I'm strongly in favor of it. This is important to resolve as part of the ABI stability and binary frameworks projects which are top goals of Swift 5. > Is the problem being addressed significant enough to warrant a change to > Swift? > Yes. > Does this proposal fit well with the feel and direction of Swift? > Yes, absolutely, in a couple of ways:
- This design abides by the goal of progressive disclosure: you’re completely unaffected by it (and don’t have to think about it) until you are publishing a public enum outside of your module. - This is a "safe default”: if someone forgets to think about how their enum will be used, it will design to being non-exhaustive. If this becomes a problem in practice for their clients, they’d get notified of that and can (without breaking abi compatibility with previous releases) opt into exhaustiveness. If the parity is reversed, this won’t be the case. > If you have used other languages or libraries with a similar feature, how do > you feel that this proposal compares to those? > Swift is an uncommon language because it aims to support both static compilation and long-term API/ABI stability. Many other languages choose one over the other: e.g. C++ is good at static compilation, but not long-term API/ABI stability (fragile base class problem, and C enums, etc). Java is good at long-term API stability, but not great for static compilation. The closest analog I’m familiar with is the Objective- part of Objective-C, which is great at API/ABI stability . Unfortunate, it inherited its enum model from C, and we are well aware of how problematic they are for framework evolution. This approach is a great solution to the problems found through decades of experience evolving APIs that use these C enums. > How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? > A lot of time. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
