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. > Le 10 janv. 2018 à 23:31, Chris Lattner via swift-evolution > <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 > https://lists.swift.org/mailman/listinfo/swift-evolution -- Michel Fortin https://michelf.ca
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution