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.
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 < swift-evolution@swift.org> 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.
extension Equatable where Self : Codable {
static func == (lhs: Self, rhs: Self) -> Bool {
// serialize lhs and rhs and compare the archives.
}
}
That would probably function (if not necessarily perform) almost as
well.
···
on Fri May 26 2017, Logan Shire <swift-evolution@swift.org> 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.