[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Jordan Rose]

Thanks for your feedback! I think you're missing the "libraries in the OS" aspect of this: if there are Swift libraries in iOS, and Apple ships a software update, some enums will get new cases. That means you can always end up in a default case if you were switching over those enums, and that's why 'switch!' has a '!' in it.

I sympathize with the "exhaustiveness diagnostics must be preserved" idea, but it simply doesn't account for package-based development. If libraries are allowed to add new cases without breaking source stability, they must not introduce new errors into clients. An app author cares about that because they want to use the latest Apple SDKs right away, even before any of their third-party library dependencies have released an update.

I do actually expect a number of third-party libraries to both mark their enums as exhaustive and add new cases in major releases (the ones that are allowed to be source-breaking). It's also a source-compatible change to mark a public enum as "exhaustive" that wasn't before, so I also expect an early flurry of bug reports when people realize this is important in Swift 5. But I think people will get the hang of it.

To be clear, I'm open to ideas in this space. It's just that both of the ideas in "Alternatives Considered" feel incomplete to me, and unfortunately we do have to do something in the near term for both imported enums and for Apple APIs (the overlays).

Jordan


> On Dec 20, 2017, at 01:44, Jérôme Duquennoy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi guys,
> 
> I am part of the people mentioned in "Preserve exhaustiveness diagnostics for non-exhaustive enums" : I see the completeness check as a major feature of enums, that makes a difference between it and a list of constants in multiple cases.
> So much that in the coding rules of the company I work for, the use of default case requires some specific justification at review time.
> 
> I have a positive opinion on this evolution if it comes with a solution to preserve exhaustiveness diagnostics. Otherwise, I think it lowers the ease of maintenance of code using external libraries.
> 
> One of the risk I fear is that libraries builders might just forget to add the @exhaustive keyword. So it might end up being a pretty common case to have to specify "I want this switch to be exhaustive", just to not loose on maintainability. This could lead to a situation similar to the "fileprivate", that ended up being used much more than expected.
> 
> It is not exactly in the scope of that review, but in the two solution for enforcing exhaustiveness drafted in that proposal, I would rather avoid the second one (the switch!). It would contradict the fact that as of today, the use of the exclamation mark in swift is a pretty clear sign that you are disabling some compiler-provided security at your own risk, and that it might lead to runtime crash (force unwrap, force cast, ...).
> Here, requesting a switch to be exhaustive is adding one more compiler check. It cannot lead to a runtime crash.
> I will be happy to discuss it further in a future review.
> 
> Jerome
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/50e95ba4/attachment.html>