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

Gwendal Roué gwendal.roue at gmail.com
Fri Jan 5 03:11:34 CST 2018

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180105/7c86f485/attachment.html>

More information about the swift-evolution mailing list