Sent from my iPhone
> On Jan 13, 2017, at 13:51, Adam Shin via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> When using enums with associated values, it's often necessary to check for
> equality between two enum objects in some way. That can lead to boilerplate
> code like this:
>
> enum Option {
> case foo(String)
> case bar(Int)
> case zip
> }
>
> func ==(lhs: Option, rhs: Option) -> Bool {
> switch (lhs, rhs) {
> case (.foo(let a), .foo(let b)) where a == b: return true
> case (.bar(let a), .bar(let b)) where a == b: return true
> case (.zip, .zip): return true
> default: return false
> }
> }
>
> ..which results in code duplication and opens the door to potential logic
> errors.
>
> Instead, what if enums with associated values were automatically Equatable
> when all their associated values were Equatable? That would remove the need
> for such boilerplate code.
>
> The Swift language guide states that custom classes and structs don't receive
> a default implementation of the == operator because the compiler can't guess
> what "equality" means for them. However, I think this could make sense for
> enums. An enum case, even with associated values, seems closer to a value
> itself than an object with logic and state.
>
> I'd be interested to hear any thoughts on this. Would this be a beneficial
> addition?
I think it makes more sense to come up with some syntax for reducing that kind
of boilerplate code in general. In "pseudo-english", I'd write the == function
as "if lhs and rhs are the same case && their associated values are the equal,
return true, else return false".
What about doing something with the reflection system? Isn't that supposed to
get overhauled for Swift 4? I'm not sure what the performance implications
would be, though.
- Dave Sweeris _______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
