[swift-evolution] Handling unknown cases in enums [RE: SE-0192]
jordan_rose at apple.com
Tue Jan 16 12:17:30 CST 2018
> On Jan 13, 2018, at 18:33, Chris Lattner <clattner at 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.
> 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.
>> On Jan 12, 2018, at 10:49 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Jan 12, 2018, at 3:08 PM, Jordan Rose <jordan_rose at 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.)
>> 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
More information about the swift-evolution