This is correct behavior in today's Swift: overload resolution is done at compile time, and operators are never dynamically dispatched even when used in protocols. If you want dynamic dispatch behavior, you'll have to use a helper function like NSObject's isEqual(_:).

There are a few open discussions about changing this behavior in some way; if we decide not to, we should see if we can make it more obvious that this is happening.

Comment by Jon Nørrelykke (JIRA)

The result of that design decision is that
{{ x (x == y) }}.
which is very misguiding, since both x and y implement Equatable, and Equatable states that != is automatically computed from ==.

@belkadan Are you sure that operators are never dynamically dispatched to? The following example dispatches to Foo's == overload (I don't see how this could be achieved with static dispatch without specialising the generic function):

struct Foo : Equatable {
    static func ==(lhs: Foo, rhs: Foo) -> Bool {
        print("foo's ==")
        return true
    }
}

func areEqual<T : Equatable>(lhs: T, rhs: T) -> Bool {
    return lhs == rhs // dynamically dispatch
}

let f = Foo()
_ = areEqual(lhs: f, rhs: f) // foo's overload is called

I think the problem is that an == overload for a subclass isn't added to the protocol witness table when its superclass already conforms to Equatable (or the subclass doesn't even get it's own protocol witness table for Equatable conformance in the first place?).

Sorry, I meant == isn't dispatched like a class method; you are correct that it is dispatched dynamically like a protocol requirement. But yes, the subclass does not get to provide new members to satisfy the conformance. This is important because a protocol can be added to a base class in one module and a subclass created in another module. (It's not the only design decision, but it is the design we have today, and any change would have to go through the Swift Evolution Process.)

Note that we now allow protocols to be defined inside types, but class operators still need to be final. However at least now the syntax makes sense for allowing overridable operators to be defined; I think at this point it's just a matter of implementation.

Comment by Ryan Lovelett (JIRA)

For my team, another point of consideration is a class that extends NSManagedObject it is illegal to override NSObject's isEqual. AFAICT it is used internal to CoreData and cannot safely be changed.

class SubClass : NSManagedObject {

  ...

  static func == (lhs: SubClass, rhs: SubClass) -> Bool {
    ...
  }

  // ❌ Crashes at runtime with: ❌
  // "Class 'SubClass' for entity 'SubClass' has an illegal override of NSManagedObject -isEqual:"
  override func isEqual(_ object: Any?) -> Bool {
    guard let rhs = object as? SubClass else {
      return false
    }
    return self == rhs
  }

}

This basically means that any custom sub-class of NSManagedObject cannot really be Equatable. There are just too many edge cases where it will fall into dynamic dispatch; like if it is in an Sequence, Optional, or ImplicitlyUnwrappedOptional.

To me, it certainly is not obvious at the call site which path the code will take. I think this violates the principle of least astonishment.

I suppose it is worth noting that in Swift 3.1 SubClass! would have called the == override but in Swift 3.2 it now behaves like SubClass? does.

Comment by Grigory Entin (JIRA)

I wonder if some kind of diagnostics, or anything at compile time would be possible in this case. At quick glance, it looks like it makes sense either to make/treat such methods (utilizing default protocol implementation) as "final" in base class (because effectively you can not override them at all, even though they're "present" in the base class) or at least provide a warning on attempt to define the matching method in the subclass (I don't know how such a warning could be suppressed though).

I believe this thing (mixing subclasses and protocols/different kinds of "dynamic dispatch" for protocols and classes) should be covered somehow in the documentation, to avoid the confusion.