This is distinct from conditional conformances (we could add this feature today).
~Robert Widmann > On Jan 17, 2017, at 8:59 PM, Andy Chou <[email protected]> wrote: > > Yes, here's a reference to the conditional conformance proposal which was > accepted: > > https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> > > 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. > > Andy > >> On Jan 17, 2017, at 5:45 PM, Robert Widmann <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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? >> >>> On Jan 17, 2017, at 7:15 PM, Andy Chou via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Enums with associated values can be very useful in Swift, but once you add >>> associated values you lose some properties, especially equality: >>> >>> ``` >>> enum AuthenticationResponse { >>> case success >>> case alert(Alert) >>> case reauthenticate >>> } >>> ``` >>> >>> Testing for a specific case requires a switch statement or the if pattern >>> match syntax: >>> >>> if case .success = response { … } >>> >>> 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: >>> >>> ``` >>> enum AuthenticationResponse { >>> case success >>> case alert(Alert) >>> case reauthenticate >>> >>> var isSuccess: Bool { >>> if case .success = self { >>> return true >>> } else { >>> return false >>> } >>> } >>> >>> var isReauthenticate: Bool { >>> if case .reauthenticate = self { >>> return true >>> } else { >>> return false >>> } >>> } >>> >>> var isAlert: Bool { >>> if case .alert(_) = self { >>> return true >>> } else { >>> return false >>> } >>> } >>> } >>> ``` >>> Any suggestions better than writing out each of these functions explicitly? >>> >>> 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: >>> >>> assert(response == .success) >>> >>> This is perfectly intelligible and I would argue that equality should be >>> defined for enums with associated values omitted: >>> >>> assert(response == .alert) >>> >>> Here we are ignoring the associated values, and merely checking if the enum >>> case is the same. >>> >>> Andy >>> >>> _______________________________________________ >>> 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
