[swift-evolution] Warning when omitting default case for imported enums

Slava Pestov spestov at apple.com
Thu Feb 9 20:28:11 CST 2017

> On Feb 8, 2017, at 1:34 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
>> Allowing the omission of a default case in an exhaustive switch makes the addition of a new case to the enum a breaking change. 
> Depending on the context, even with a default the change might be breaking — but without giving notice to the framework client!
> Additionally, it would feel very strange for me to have a default clause for bool-like enums* or other examples where there can't be any additional cases.
> When there are two types of enums, the proposal makes sense for the "open"-ones; but I'm not sure if I like the concept of having two kinds of enum.

Why not? Bool-like enums would be declared ‘closed’, and would not require a default case (but adding a new case would then break ABI).

For better or worse we need the ability to define enums that admit new cases without breaking ABI. Whether or not this is the default for all enums, or enabled with a special attribute can be designed later when we send out evolution proposals for resilience-related features.


> - Tino
> * tiny anecdote: I actually have seen the equivalent of this
> func reallyExhaustive(input: Bool) {
> 	if input == true {
> 		print("true")
> 	} else if input != true {
> 		print ("not true")
> 	} else {
> 		print("just to be save")
> 	}
> }
> in the wild… but I don't remember the comment I wrote ;-)
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

More information about the swift-evolution mailing list