On Tue, Jan 2, 2018 at 11:45 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:
> On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >> [Proposal: https://github.com/apple/swift-evolution/blob/mas >> ter/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 > > 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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution