> On Jan 13, 2017, at 12:14 PM, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > I think the “when all their associated values were Equatable” is the > technical issue holding this type of thing up. The ability to spell that > type of thing is on the generics roadmap, but I don’t know when it will > actually happen. There seem to be a lot of things on hold because of it.
The proposal for conditional conformances was accepted. However, right now the generics feature being worked on is recursive conformances, together with a large overall cleanup of the generics implementation to fix bugs and improve correctness. Conditional conformances will come at some point after that. Slava > > Thanks, > Jon > >> On Jan 13, 2017, at 11:51 AM, Adam Shin via swift-evolution >> <[email protected] <mailto:[email protected]>> 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? >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
