[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums
panajev at gmail.com
Wed Dec 20 16:44:58 CST 2017
> 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.
Standing ovation :), one of my most loved warnings in -Weverything was ensuring switches were exhaustive.
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution