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.r...@gmail.com> wrote:
>
>
>> Le 5 janv. 2018 à 09:11, Goffredo Marocchi via swift-evolution
>> <swift-evolution@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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
