> On Jan 13, 2018, at 18:33, Chris Lattner <clatt...@nondot.org> wrote: > > 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.
I did not think about this. You're right, we could allow that syntax. We don't currently have any hash-prefixed constructs that aren't "top-level", but that's not a rule or anything. Jordan > > 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
