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

[Michel Fortin]

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 at swift.org> a écrit :
> 
> 
>> On Jan 10, 2018, at 10:10 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



-- 
Michel Fortin
https://michelf.ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180111/5b8c13ba/attachment.html>