[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose]

> 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.

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 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.)
>> 
>> 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution