I've been working on this very thing for a while :) Proposal PR: https://github.com/apple/swift-evolution/pull/706
Implementation PR: https://github.com/apple/swift/pull/9619 I was really hoping to get it into Swift 4 but the deadline is fast approaching, he proposal hasn't been officially reviewed yet (there's a thread on this list from a few weeks ago where we hashed out a couple drafts), and the implementation, based on the smoke test, seems to have a strange issue that only occurs on Linux (assuming it's not unrelated) that I haven't been able to track down yet. On Fri, May 26, 2017 at 9:10 AM Logan Shire via swift-evolution < [email protected]> wrote: > Given we now have precedent in the form of the derived Codable conformance > coming in Swift 4.0, > it begs the question why we don’t offer the same behavior for value types > that declare themselves to be Equatable > and have all Equatable properties. E.g. > > struct A: Equatable { > let foo: String > let bar: Int > } > > struct B: Equatable { > let baz: Double > } > > struct C: Equatable { > let a: A > let b: B > } > > let a = A(foo: “hello”, bar: 1) > let a2 = A(foo: “hello”, bar: 2) > a == a2 // false > let b = B(baz: 3.1) > let c = C(a: a, b: b) > le c2 = C(a: a2, b: b) > c == c2 // false > > You would always be free to shadow the provided implementation: > > extension A { > func ==(lhs: A, rhs: A) { > return lhs.foo == rhs.foo > } > } > > a == a2 // true > > It’s up for debate whether this should apply to reference types, or > Hashable, but at a bare minimum we should > offer it for value types consisting of Equatable value types that > explicitly declare but don’t implement the conformance. > > Thanks! > _______________________________________________ > 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
