[swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

Thomas Roughton t.roughton at me.com
Sat Dec 23 17:47:23 CST 2017

> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> wrote:
> What are your thoughts on `final switch` as a way to treat any enum as exhaustible?
> https://dlang.org/spec/statement.html#FinalSwitchStatement
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I’d be very much in favour of this (qualms about the naming of the ‘final’ keyword aside - ‘complete’ or ‘exhaustive’ reads better to me). 

Looking back at the proposal, I noticed that something similar was mentioned that I earlier missed. In the proposal, it says:

> However, this results in some of your code being impossible to test, since you can't write a test that passes an unknown value to this switch.

Is that strictly true? Would it be theoretically possible for the compiler to emit or make accessible a special ‘test’ case for non-exhaustive enums that can only be used in test modules or e.g. by a ‘EnumName(testCaseNamed:)’, constructor? There is  potential for abuse there but it would address that particular issue. 

Regardless, I still feel something like a ‘final switch’ is necessary if this proposal is introduced, and that it fits with the ‘progressive disclosure’ notion; once you learn this keyword you have a means to check for completeness, but people unaware of it could just use a ‘default’ case as per usual and not be concerned with exhaustiveness checking. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171224/7fd6680c/attachment.html>

More information about the swift-evolution mailing list