> On Aug 8, 2017, at 3:28 PM, Jordan Rose via swift-evolution 
> <swift-evolution@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 

Brent Royal-Gordon

swift-evolution mailing list

Reply via email to