<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2017, at 1:15 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This is a request that comes up frequently; I wrote an early draft proposal for it several months ago, with it covering all value types, not just enums, and also including Hashable as well as Equatable:<div class=""><br class=""></div><div class=""><a href="https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad" class="">https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad</a><br class=""></div><div class=""><br class=""></div><div class="">Since it's purely additive, it won't get much attention until phase 2 at the earliest, but I'd like to revisit it then. Most of the discussion before revolved around to what degree users should have to opt-in or opt-out of this functionality.</div></div></div></blockquote><div><br class=""></div>I think if someone were to implement this though, we would be happy to merge it in. The code for deriving Equatable and Hashable conformances is in these files:</div><div><br class=""></div><div>lib/Sema/CodeSynthesis.cpp</div><div>lib/Sema/DerivedConformances.cpp</div><div>lib/Sema/DerivedConformanceEquatableHashable.cpp</div><div><br class=""></div><div>I agree it should be opt-in though (I would also argue that even the no-payload enum behavior should be opt-in, but that ship has sailed).</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Re: generics, I don't think there's anything on the roadmap that goes into such deep detail as "if every associated value of every enum case is Equatable, then X is also Equatable", and I don't think there would be a clean way to express that with the generics syntax. This would probably have to be something that's baked into the compiler to synthesize == and hashValue for types that satisfy the constraints.</div></div></div></blockquote><div><br class=""></div>The generics feature people are thinking of is conditional conformances:</div><div><br class=""></div><div>extension Array : Equatable where Element == Equatable { … }</div><div><br class=""></div><div>However it does not solve the problem for enums with associated values because as you said there’s no way to quantify over ‘all associated values’ in the language, and this is not planned.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jan 13, 2017 at 12:31 PM David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Sent from my iPhone</div></div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg">On Jan 13, 2017, at 13:51, Adam Shin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg" style="font-size:13px">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:<br class="gmail_msg"></div><div class="gmail_msg" style="font-size:13px"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size:13px">enum Option {</div><div class="gmail_msg" style="font-size:13px"> case foo(String)</div><div class="gmail_msg" style="font-size:13px"> case bar(Int)</div><div class="gmail_msg" style="font-size:13px"><span class="gmail_msg m_-8103148186215456657inbox-m_-1513968597867029764Apple-tab-span" style="white-space:pre-wrap"> </span>case zip</div><div class="gmail_msg" style="font-size:13px">}</div><div class="gmail_msg" style="font-size:13px"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size:13px">func ==(lhs: Option, rhs: Option) -> Bool {</div><div class="gmail_msg" style="font-size:13px"> switch (lhs, rhs) {</div><div class="gmail_msg" style="font-size:13px"> case (.foo(let a), .foo(let b)) where a == b: return true</div><div class="gmail_msg" style="font-size:13px"> case (.bar(let a), .bar(let b)) where a == b: return true</div><div class="gmail_msg" style="font-size:13px"> case (.zip, .zip): return true</div><div class="gmail_msg" style="font-size:13px"> default: return false</div><div class="gmail_msg" style="font-size:13px"> }</div><div class="gmail_msg" style="font-size:13px">}</div><div class="gmail_msg" style="font-size:13px"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size:13px">..which results in code duplication and opens the door to potential logic errors.</div><div class="gmail_msg" style="font-size:13px"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size:13px">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.</div><div class="gmail_msg" style="font-size:13px"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size:13px">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.</div><div class="gmail_msg" style="font-size:13px"><br class="gmail_msg"></div><div class="gmail_msg" style="font-size:13px">I'd be interested to hear any thoughts on this. Would this be a beneficial addition?</div></div></div></blockquote><br class="gmail_msg"></div><div dir="auto" class="gmail_msg"><div class="gmail_msg">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".</div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">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.</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">- Dave Sweeris </span></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>