I don’t understand why #unknown wouldn’t work in catch clauses. In the absence of typed throws you can’t match on an enums case without the enums base: you can’t use .foo, you have to use MyEnum.foo.
Similarly, catch wouldn’t allow .#unknown, it would require MyEnum.#unknown. This is perfectly well defined and just falls out of the model. That said, I agree that the issue of source dependencies that might use this is a significant problem. IMO, that argues strongly for “unknown default:” producing a warning. -Chris > On Jan 12, 2018, at 10:49 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jan 12, 2018, at 3:08 PM, Jordan Rose <jordan_r...@apple.com> wrote: >> >> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's >> point very specifically: if the compiler emits an error, we should go with >> `case #unknown` instead. (I'm very strongly in the "warning" camp, though.) > > Thanks! > > Out of curiosity, why not “unknown default:”? The “warning” behavior is a > customization of default, so this seems like a more logical model. It also > fits into the existing Swift grammar, unlike “unknown case:” which requires > adding a new special case production. > > -Chris > > _______________________________________________ > 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
