[swift-evolution] Equatability for enums with associated values

Slava Pestov spestov at apple.com
Fri Jan 13 16:12:11 CST 2017

> On Jan 13, 2017, at 12:14 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> 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.


> Thanks,
> Jon
>> On Jan 13, 2017, at 11:51 AM, Adam Shin via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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?
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170113/607e189c/attachment.html>

More information about the swift-evolution mailing list