> On Aug 8, 2017, at 3:28 PM, Jordan Rose via swift-evolution
> <firstname.lastname@example.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
(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
swift-evolution mailing list