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

[Cheyo Jimenez]

> On Dec 21, 2017, at 9:49 AM, Ignacio Soto via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I think I speak for the entire Swift community when I say that Swift's enums, together with the ability to switch over them exhaustively and having compile-time guarantees, is one of the best features in Swift. I'm regularly annoyed by this when writing other languages like Java and JS (default: throw new IllegalArgumentException();)
> 
> Now, that's not to say I don't understand why this proposal is necessary. I totally get it, and the existing decisions make a lot of sense to me. But I'd like us to introduce this while maintaining the ability to guarantee exhaustive switch statements, no matter how the enum was defined.
> 
> Example: imagine a theoretical SampleKit defines:
> public enum E {
> case A
> case B
> }
> 
> It's implicitly non-exhaustive, possibly because the author was not aware of the default (which would likely happen often), or possibly because they made a conscious decision, as they expect to expand the cases in the future.
> 
> In my app, I use SampleKit and decide that I want to make sure I handle all cases:
> 
> switch e {
> case A: break
> case B: break
> default: break // This becomes necessary
> }
> 
> As the proposal stands right now, I'm forced to handle any future cases. That's fine. What's not fine in my opinion, is that in doing so I lose the ability to keep this exhaustiveness moving forward. If I update SampleKit to v2.0, I want to know at compile-time if there are new cases I need to be aware of (instead of going to some generic handling path). Instead, I’m left in the same place I would in other languages like Java or JS:
> 
> // No error :(
> switch e {
> case A: break
> case B: break
> default: break
> }
> 
> Proposed Solution
> 
> What I’m proposing is that we introduce a new keyword, unknown (or a better name), that serves as a way to handle cases that aren’t yet known, but not those that are.
> 
> // Error: missing case C
> switch e {
> case A: break
> case B: break
> unknown: break // Would handle future cases
> }
> 

What are your thoughts on `final switch` as a way to treat any enum as exhaustible?
https://dlang.org/spec/statement.html#FinalSwitchStatement


> With this, you shouldn’t be able to use default AND unknown at the same time, as default implicitly includes unknown.
> 
> Thanks for reading, and I hope you can consider this change (or some variation of it).
> 
> Nacho Soto
> _______________________________________________
> 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/20171223/a0efce29/attachment.html>