> On Jan 2, 2018, at 18:07, Jordan Rose <jordan_r...@apple.com> 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!
I ended up doing these in the opposite order, writing up the new proposal first
and not yet responding to the discussion that's further out. You can read my
revisions at https://github.com/apple/swift-evolution/pull/777.
In particular, I want to at least address:
- Dave D and Drew C's points about versioned libraries / linking semantics of
modules.
- Jason M's point about migration
and I'll do one more pass over the thread to see if there's anything else I
didn't address directly. (That doesn't mean everyone who disagrees, just
messages where I think there's more I can do to explain why the proposal is the
way it is.)
Jordan
P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
