[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Ben Rimmington]

> On 3 Jan 2018, at 02:07, Jordan Rose wrote:
> 
> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md <https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md>]
> 
> Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems that most people seem to like '@frozen', and that does in fact have the connotations we want it to have. I like it too.

Should there be a new Clang attribute for "frozen" enums? Then the existing `__attribute__((enum_extensibility(closed)))` would only prevent "private" cases (and not future "public" cases).

<https://clang.llvm.org/docs/AttributeReference.html#enum-extensibility-clang-enum-extensibility>

> More seriously, this discussion has convinced me that it's worth including what the proposal discusses as a 'future' case. The key point that swayed me is that this can produce a warning when the switch is missing a case rather than an error, which both provides the necessary compiler feedback to update your code and allows your dependencies to continue compiling when you update to a newer SDK. I know people on both sides won't be 100% satisfied with this, but does it seem like a reasonable compromise?
> 
> The next question is how to spell it. I'm leaning towards `unexpected case:`, which (a) is backwards-compatible, and (b) also handles "private cases", either the fake kind that you can do in C (as described in the proposal), or some real feature we might add to Swift some day. `unknown case:` isn't bad either.

You might end up with `case .unknown:` and `unknown case:` in the same switch.

e.g. <https://developer.apple.com/documentation/photos/phassetmediatype>

	```
	switch mediaType {
	case .image, .video, .audio:
	    break
	case .unknown:
	    break
	unknown case:
	    break
	}
	```

-- Ben

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