> On Feb 8, 2017, at 1:34 AM, Tino Heth via swift-evolution
> <swift-evolution@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.
Slava
>
> - 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
