> Le 5 janv. 2018 à 09:11, Goffredo Marocchi via swift-evolution
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
