[swift-evolution] Enums and Source Compatibility

[Brent Royal-Gordon]

> On Aug 8, 2017, at 3:28 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Let's now flip this to the other side of the equation. I've been talking about us disallowing exhaustive switching, i.e. "if the enum might grow new cases you must have a 'default' in a switch". In previous (in-person) discussions about this feature, it's been pointed out that the code in an otherwise-fully-covered switch is, by definition, unreachable, and therefore untestable. This also isn't a desirable situation to be in, but it's mitigated somewhat by the fact that there probably aren't many framework enums you should exhaustively switch over anyway. (Think about Apple's frameworks again.) I don't have a great answer, though.
> 
> For people who like exhaustive switches, we thought about adding a new kind of 'default'—let's call it 'unknownCase' just to be able to talk about it. This lets you get warnings when you update to a new SDK, but is even more likely to be untested code. We didn't think this was worth the complexity.

A question: Does it make sense to switch on a non-exhuastive enum at all? Maybe, from the public vantage point, a closed enum should be indistinguishable from a struct with static properties/methods—if you can switch over one, it's only through its conformance to `Equatable` or its implementation of a public `~=` operator.

(IIRC, we ended up somewhere quite similar to this with our "import Objective-C string constants as enums" feature—it actually ends up creating structs instead.)

-- 
Brent Royal-Gordon
Architechies

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