> On Jan 11, 2018, at 05:08, Michel Fortin <michel.for...@michelf.ca> wrote: > > I think `unknown` should be a modifier for either `case` or `default`. This > would allow: > > unknown default: > unknown case _: // similar to default > unknown case (1, _): // enum in second position > > If the case can be reached with statically known enum values, the compiler > generates a warning. > > I'd also prefer a more precise term instead of "unknown". What we aim at is > matching cases that do not have a declaration (future cases, > privately-declared cases). So I'd use the word "undeclared" rather than > "unknown": > > undeclared default: > undeclared case _: // similar to default > undeclared case (1, _): // enum in second position > > That word has the advantage that enums are also less likely to have a case > named "undeclared", I think.
I’m not sure I’d agree that most people would think of private cases are “undeclared”, but sure, it’s a reasonable alternative. I still like “unknown” a little better myself. Jordan > >> Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> >>> On Jan 10, 2018, at 10:10 AM, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>>>> >>>>> - Matching known cases is a feature, not a limitation, to avoid existing >>>>> code changing meaning when you recompile. I'll admit that's not the >>>>> strongest motivation, though, since other things can change the meaning >>>>> of existing code when you recompile already. >>>> >>>> I’m not sure I understand this. >>>> >>>> The whole motivation for this feature is to notify people if they are not >>>> handling a “newly known” case. If they don’t care about this, they can >>>> just use default. >>> >>> Notify, yes. Error, no. It's a design goal that adding a new case does not >>> break source compatibility in addition to not breaking binary compatibility >>> (because people don't like editing their dependencies) and therefore the >>> behavior has to be defined when they recompile with no changes. >>> >> >> Ok, if that’s the desired design, then (IMO) the right way to spell it is >> “unknown default:” and it should have semantics basically aligned with the >> design you laid out in the revision of the proposal. If this is supposed to >> be an error, then it should be a pattern production. >> >> Do you have a sense for whether this is what people want? We really should >> have a review cycle evaluating exactly this sort of tradeoff. >> >> In any case, I’ve said this before off-list, but I find this whole >> discussion (of how to improve diagnostics for unknown cases) to be separable >> from the core issue required to get to ABI stability. It seems to me that >> we could split this (ongoing) design discussion off into a separate SE, >> allowing you to get on with the relatively uncontroversial and critical >> parts in SE-0192. >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > -- > Michel Fortin > https://michelf.ca <https://michelf.ca/>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
