[swift-evolution] Polymorphic behavior for overloaded == (and other) operators

[Frederick Kellison-Linn]

Currently, implementing an ‘==‘ function for a custom class can be somewhat cumbersome. In the simple hierarchy:

class A {
    var a: Int
    init(_ a: Int) {
        self.a = a
    }
}

class B : A {
    var b: Int
    init(_ b: Int, _ a: Int) {
        self.b = b
        super.init(a)
    }
}

A reasonable implementation of == would seem to be

func ==(lhs: A, rhs: A) -> Bool {
    return lhs.a == rhs.a
}

func ==(lhs: B, rhs: B) -> Bool {
    return lhs.a == rhs.a &&
           lhs.b == rhs.b
}

However, this fails in the case that the static type of compared variables differs from their dynamic type. E.g:

let x = A(3)
let y: A = B(3, 4)

x == y // true

The immediately obvious solution is to add a check to every == implementation that may need to be implemented for a subtype:

func ==(lhs: A, rhs: A) -> Bool {
    if (lhs.dynamicType != rhs.dynamicType) {
        return false
    }
    return lhs.a == rhs.a
}

But this results in annoying boilerplate for what should be a simple computation, and furthermore fails to solve every case:

let w: A = B(1, 2)
var z: A = B(1, 3)

w == z // still true

I’d be interested to know if there is any interest taken in this problem and whether possible solutions have been discussed. If == were instead behaved as if it were a method of its first argument (as in a .equals(other) method) then the solution above is sufficient to avoid returning the wrong result, but being forced to use .dynamicType for something as basic as equality checking seems cumbersome to me.

FKL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/abcbecb3/attachment.html>