> On Aug 8, 2017, at 3:28 PM, Jordan Rose via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
