> On Sep 28, 2017, at 4:15 PM, Goffredo Marocchi via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Agreed, I am not seeing this change doing so much good because maybe it could
> prevent issues Library writers or developers updating libraries without
> checking things... not trying to be rude and/or non empathetic, but
> exhaustive enums never struck me as a bad thing and the reasons why they
> could be bad very quickly leads one to think “maybe you should not have been
> switching on enums there...”.
You're suggesting that we use enums when something is known to be exhaustive,
and then something like this when it's not?
struct SomeOptionSetOrWhatever : Equatable, RawRepresentable {
public static func == (lhs: SomeOptionSetOrWhatever, rhs:
SomeOptionSetOrWhatever) -> Bool { return lhs.value == rhs.value }
public static let optionOne = SomeOptionSetOrWhatever(privateInit: 1)
public static let optionTwo = SomeOptionSetOrWhatever(privateInit: 2)
private let value: Int
private init(privateInit value: Int) { self.value = value }
public init?(rawValue: Int) {
switch rawValue {
case 1: self = .optionOne
case 2: self = .optionTwo
case _: value = 0; return nil
}
}
public var rawValue: Int { return value }
}
func foo(x: SomeOptionSetOrWhatever) {
switch x {
case .optionOne: print("first option")
case .optionTwo: print("second option")
default: break //without this line, it's a "switch much be exhaustive"
error
}
}
- Dave Sweeris_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
