Sent from my iPhone
> On 3 Jan 2018, at 07:42, Goffredo Marocchi <pana...@gmail.com> wrote: > > >> On 3 Jan 2018, at 02:07, Jordan Rose via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> [Proposal: >> 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? > > If we can optionally treat this warning as an error yeah, but considering the > restricted use case, the default should still be exhaustive with unfrozen the > optional keyword that can be applied to opt out of the error. > > Regardless of that, if it is not going to cause runtime issues why should it > not be a compile time error and just a warning? I think if you recompile the > app and are either targeting a new SDK or updating a library you bundle that > you should have to address this issue. Still, better than nothing :). > >> >> 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 >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
