[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Goffredo Marocchi]

Fair concerns Gwendal, but why can’t the default in these cases be just exhaustive / frozen unless the library developer explicitly marks it as “unfrozen/non exhaustive” and the compiler can warn the users when they switch over it instead of throwing an error by default (the user can still treat warnings as errors if they want and suppress this warning if they wanted to in this vision)?

I think, sorry if I am being presumptions, that the onus in this case should be on the library author to mark enums and opt in in this non exhaustive behaviour. @Jordan what would the issue in this be?

Sent from my iPhone

> On 5 Jan 2018, at 09:11, Gwendal Roué <gwendal.roue at gmail.com> wrote:
> 
> 
>> Le 5 janv. 2018 à 09:11, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> I feel like this change will make the life easier for library authors, but risks making it easier and easier to make mistakes in apps using the libraries: exhaustive switching over enums is a good important feature that risks going away (the default matters) for not a huge effective benefit to app developers.
> 
> I agree that life is made worse for a library user that meets a non-frozen enum. And I don't know if it makes the life easier for library authors, because library authors not only throw code in the wild, but also try to prevent library users from making the mistakes you talk about.
> 
> To take GRDB.swift as an example, it currently has 15 public enums. What are my options?
> 
> More than half of those enums mirror SQLite C enums, or sets of related SQLite values. SQLite is still a living piece of sofware, and it may adds new cases or values in the future. It is then likely that GRDB has to be updated as well. It thus looks like I can make those enums @frozen. But then it looks like I betray the proposal's goal. What's the correct choice?
> 
> Some enums are like SKPaymentTransactionState: there's no way the user could infer a proper behavior in a mandatory default/unknown switch case. I thus also want to make them @frozen, and avoid headaches to the library users. Will I pay for it later?
> 
> Some other enums are positively non-frozen. I may want to replace some of them with a struct with a limited set of pre-built values. This would, IMHO, improve the library UX because it would again prevent headaches for the library users about scary "future" cases. In the struct with a limited set of values, there is no future cases. Instead, there are a limited set of named values. Which is a very different way to say the same thing.
> 
> This last paragraph draws a strong parallel between non-frozen enums and structs:
> 
>     // non-frozen enum:
>     public enum E {
>         case a, b
>     }
>     
>     // equivalent struct:
>     public struct S: Equatable {
>         private let value: Int
>         private init(_ value: Int) { self.value = value }
>         public static let a = S(1)
>         public static let b = S(2)
>         public static func == (lhs: S, rhs: S) -> Bool {
>             return lhs.value == rhs.value
>         }
>     }
> 
>     func f(_ s: S) {
>         // S can be switched over just like a struct:
>         switch s {
>         case .a: print("a")
>         case .b: print("b")
>         default: print("unknown")
>         }
>     }
> 
> BTW, did anybody think about importing C enums as such structs?
> 
> Gwendal
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180105/e9e818ca/attachment.html>