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

[Dave DeLong]

> On Jan 2, 2018, at 10:26 PM, Kelvin Ma via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> On Tue, Jan 2, 2018 at 11:45 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> [Proposal: 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>]
> 
> Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems that most people seem to like '@frozen', and that does in fact have the connotations we want it to have. I like it too.
> 
> More seriously, this discussion has convinced me that it's worth including what the proposal discusses as a 'future' case. The key point that swayed me is that this can produce a warning when the switch is missing a case rather than an error, which both provides the necessary compiler feedback to update your code and allows your dependencies to continue compiling when you update to a newer SDK. I know people on both sides won't be 100% satisfied with this, but does it seem like a reasonable compromise?
> 
> The next question is how to spell it. I'm leaning towards `unexpected case:`, which (a) is backwards-compatible, and (b) also handles "private cases", either the fake kind that you can do in C (as described in the proposal), or some real feature we might add to Swift some day. `unknown case:` isn't bad either.
> 
> I too would like to just do `unknown:` or `unexpected:` but that's technically a source-breaking change:
> 
> switch foo {
> case bar:
>   unknown:
>   while baz() {
>     while garply() {
>       if quux() {
>         break unknown
>       }
>     }
>   }
> }
> 
> Another downside of the `unexpected case:` spelling is that it doesn't work as part of a larger pattern. I don't have a good answer for that one, but perhaps it's acceptable for now.
> 
> I'll write up a revision of the proposal soon and make sure the core team gets my recommendation when they discuss the results of the review.
> 
> ---
> 
> I'll respond to a few of the more intricate discussions tomorrow, including the syntax of putting a new declaration inside the enum rather than outside. Thank you again, everyone, and happy new year!
> 
> Jordan
> 
> 
> +1 to warning instead of error
> +1 to unknown/unexpected case
> +1 to “@frozen” or any other reasonable spelling, they are all fine by me.
> 
> +1 to “@tangled” because abi is complicated

+1 to “@moana” because these are all just Disney movies

>  
> 
> The one remaining problem to solve is making sure multi-module apps can leave out the unknown/unexpected case on enums from modules which are part of the app itself and thus cannot be updated independently of it. John McCall’s version-locking plan sounds promising, though we should explore the available options before finalizing a course.
> 
> Perhaps we need a concept of submodules, or supermodules, or some other way to demarcate the boundaries of a resilience domain.
> 
> Nevin
> 
> i would support a proper submodule system over some verson-locking system that only the most advanced users will probably know about. i think modules should be one level higher than what they’re currently being used for right now for lack of a better alternative (one application should never have to define more than one capital M Module). submodules shouldn’t be that hard to implement, though the submodule names should be part of ABI to avoid name mangling problems
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180103/3020d4ff/attachment.html>