<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, May 2, 2016 at 1:25 PM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Mon May 02 2016, Tony Allevato <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Open issue: Class types and inheritance<br>
><br>
> While this approach works well for value types, these static operators may not<br>
> work as expected for class types when inheritance is involved, and more work may<br>
> be needed here.<br>
><br>
> We can currently model the behavior we'd like to achieve by using a named eq<br>
> method instead of the operator itself. (Note that we are not proposing that the<br>
> function be named eq in the final design; this was done simply to perform the<br>
> experiment with today's compiler.) Then we implement both the new method and the<br>
> current == operator and compare their behaviors. For example:<br>
><br>
> protocol ProposedEquatable {<br>
> static func eq(lhs: Self, _ rhs: Self) -> Bool<br>
> }<br>
><br>
> class Base: ProposedEquatable, Equatable {<br>
> static func eq(lhs: Base, _ rhs: Base) -> Bool {<br>
> print("Base.eq")<br>
> return true<br>
> }<br>
> }<br>
> func ==(lhs: Base, rhs: Base) -> Bool {<br>
> print("==(Base, Base)")<br>
> return true<br>
> }<br>
><br>
> class Subclass: Base {<br>
> static func eq(lhs: Subclass, _ rhs: Subclass) -> Bool {<br>
> print("Subclass.eq(Subclass, Subclass)")<br>
> return true<br>
> }<br>
> }<br>
> func ==(lhs: Subclass, rhs: Subclass) -> Bool {<br>
> print("==(Subclass, Subclass)")<br>
> return true<br>
> }<br>
><br>
> func eq<T: ProposedEquatable>(lhs: T, _ rhs: T) -> Bool {<br>
> return T.eq(lhs, rhs)<br>
> }<br>
><br>
> let x = Subclass()<br>
> let y = Subclass()<br>
> let z = y as Base<br>
><br>
> eq(x, y) // prints "Base.eq"<br>
> eq(x, z) // prints "Base.eq"<br>
><br>
> x == y // prints "==(Subclass, Subclass)"<br>
> x == z // prints "==(Base, Base)"<br>
><br>
> The result of eq(x, y) was a bit surprising, since the generic argument T is<br>
> bound to Subclass and there should be no dynamic dispatch at play there. (Is the<br>
> issue that since Base is the class explicitly conforming to ProposedEquatable,<br>
> this is locking in Self being bound as Base, causing that overload to be found<br>
> in the compiler's search? Or is this a bug?)<br>
><br>
> An attempt was also made to fix this using dynamic dispatch, by implementing eq<br>
> as a class method instead of astatic method:<br>
><br>
> protocol ProposedEquatable {<br>
> static func eq(lhs: Self, _ rhs: Self) -> Bool<br>
> }<br>
><br>
> class Base: ProposedEquatable, Equatable {<br>
> class func eq(lhs: Base, _ rhs: Base) -> Bool {<br>
> print("Base.eq")<br>
> return true<br>
> }<br>
> }<br>
> func ==(lhs: Base, rhs: Base) -> Bool {<br>
> print("==(Base, Base)")<br>
> return true<br>
> }<br>
><br>
> class Subclass: Base {<br>
> override class func eq(lhs: Base, _ rhs: Base) -> Bool {<br>
> print("Subclass.eq(Base, Base)")<br>
> return true<br>
> }<br>
> class func eq(lhs: Subclass, _ rhs: Subclass) -> Bool {<br>
> print("Subclass.eq(Subclass, Subclass)")<br>
> return true<br>
> }<br>
> }<br>
> func ==(lhs: Subclass, rhs: Subclass) -> Bool {<br>
> print("==(Subclass, Subclass)")<br>
> return true<br>
> }<br>
><br>
> func eq<T: ProposedEquatable>(lhs: T, _ rhs: T) -> Bool {<br>
> return T.eq(lhs, rhs)<br>
> }<br>
><br>
> let x = Subclass()<br>
> let y = Subclass()<br>
> let z = y as Base<br>
><br>
> eq(x, y) // prints "Subclass.eq(Base, Base)"<br>
> eq(x, z) // prints "Base.eq"<br>
><br>
> x == y // prints "==(Subclass, Subclass)"<br>
> x == z // prints "==(Base, Base)"<br>
><br>
> This helped slightly, since at least it resulting in a method on the expected<br>
> subclass being called, but this still means that anyone implementing this<br>
> operator on subclasses would have to do some casting, and it's awkward that<br>
> subclasses would be expected to write its operator in terms of the conforming<br>
> base class.<br>
><br>
> It should also be noted (code not provided here) that using instance methods<br>
> does not solve this problem, presumably for the same dispatch-related reasons<br>
> that the class methods called the version with Base arguments.<br>
<br>
Do we not have essentially all the same problems with classes, even with<br>
today's Equatable? If not, what are the differences?
<br></blockquote><div> </div></div><div dir="ltr"><div class="gmail_quote"><div>We do have some problems today, such as above where using `==` on a `(Base, Subclass as Base)` pair ends up calling `==(Base, Base)` because we lack multiple dispatch. What surprised me though was that the `eq` call between two `Subclass` instances passed to the trampoline operator ended up calling `Base.eq`. I would have expected `Subclass.eq` to be called there since the generic argument `T` was bound to `Subclass`. Today, a non-generic `==(Subclass, Subclass)` operator *does* do the right thing.</div><div><br></div><div>I mainly called it out because the problems we have with `==` today are slightly different than the problems encountered when testing out the new model. If the decision is "operators with Self constraints are fundamentally hard with classes and we don't necessarily expect them to work consistently", then that's fine, but I wanted to make sure it wasn't a hole in the proposal.</div><div><br></div></div></div></div>