> 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 

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 

    // 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?


swift-evolution mailing list

Reply via email to