<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="">This is distinct from conditional conformances (we could add this feature today).<div class=""><br class=""></div><div class="">~Robert Widmann<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 17, 2017, at 8:59 PM, Andy Chou <<a href="mailto:acchou2@gmail.com" class="">acchou2@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes, here's a reference to the conditional conformance proposal which was accepted:<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md</a></div><div class=""><br class=""></div><div class="">But as I mention in my post, there are cases it doesn't handle. Specifically, when the associated types for an enum aren't equatable themselves, it's still possible to define equality on the enum cases without associated values.</div><div class=""><br class=""></div><div class="">Andy</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 17, 2017, at 5:45 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Automatic “equatability” of aggregates that contain equatable members has been discussed on this list quite a few times. (I think I had a branch at one point that was exploring this kind of deriving mechanism… It seems to be lost to the sands of time). Everybody seems to agree that it’s a worthwhile feature, but there needs to be thought put into how it is exposed to the end user. e.g. Should we continue with silently implementing these protocols if we can, or should there be some kind of annotation to tell the compiler to only synthesize what the user wants?<br class=""><br class=""><blockquote type="cite" class="">On Jan 17, 2017, at 7:15 PM, Andy Chou via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Enums with associated values can be very useful in Swift, but once you add associated values you lose some properties, especially equality:<br class=""><br class="">```<br class="">enum AuthenticationResponse {<br class=""> case success<br class=""> case alert(Alert)<br class=""> case reauthenticate<br class="">}<br class="">```<br class=""><br class="">Testing for a specific case requires a switch statement or the if pattern match syntax:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if case .success = response { … }<br class=""><br class="">But while this works well for control flow, it doesn’t work well for cases where we want a Bool, such as assert(). There are also common situations with lists and libraries like RxSwift where a filtering function uses a Bool valued closure. In these situations the best we can do is write functions like:<br class=""><br class="">```<br class="">enum AuthenticationResponse {<br class=""> case success<br class=""> case alert(Alert)<br class=""> case reauthenticate<br class=""><br class=""> var isSuccess: Bool {<br class=""> if case .success = self {<br class=""> return true<br class=""> } else {<br class=""> return false<br class=""> }<br class=""> }<br class=""><br class=""> var isReauthenticate: Bool {<br class=""> if case .reauthenticate = self {<br class=""> return true<br class=""> } else {<br class=""> return false<br class=""> }<br class=""> }<br class=""><br class=""> var isAlert: Bool {<br class=""> if case .alert(_) = self {<br class=""> return true<br class=""> } else {<br class=""> return false<br class=""> }<br class=""> }<br class="">}<br class="">```<br class="">Any suggestions better than writing out each of these functions explicitly?<br class=""><br class="">The conditional conformances proposal coming in Swift 4 solves some of this issue, but not completely. If Alert isn’t Equatable, it is still useful to test whether the result is .success. For example:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>assert(response == .success)<br class=""><br class="">This is perfectly intelligible and I would argue that equality should be defined for enums with associated values omitted:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>assert(response == .alert)<br class=""><br class="">Here we are ignoring the associated values, and merely checking if the enum case is the same.<br class=""><br class="">Andy<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></body></html>