@swift-ci create

Q's f can still be used to provide a default implementation, so if we have a warning, we should also have a way to silence it that doesn't involve modifying Q itself.

Okay, after realizing the actual issue here is slightly different than I had originally thought, I offer this new description:

We should warn if a concrete type's inheritance and conformances result in surprising behavior with respect to which default method gets called.

e.g.

protocol P {
  func f()
}
extension P {
  func f() { print("P") }
}

protocol Q : P {
  // func f() // uncomment to generate a witness table entry for Q.f
}
extension Q {
  func f() { print("Q") }

  func test() {
    f() // dynamic dispatch through witness
  }
}

class X : P {}
class Y : X, Q {}

Y().test() // prints P rather than Q since test() calls f() through dynamic dispatch rather than statically resolving it to Q’s f()

In this case, since Y inherits from X, we end up satisfying P's requirement of f() with X's default implementation. This is despite the fact that Q also has a default implementation, and Y is declared as conforming to Q.

This is very subtle and could surprise users.

It would be nice to emit a warning on the definition of Y to help catch this issue. The warning text would need to be very easy to search for online because it's likely that this will require a relatively long explanation to help users understand what is going on.

I don't have any great suggestions on what syntax we would use to silence the warning if in fact the author of Y really intends calls to f() to call into P's default implementation of f().

What can the Y author do about this, even if that's not the desired behavior?

That's a good question, and I think it would require language additions. One possible approach would be to:

• Add a mechanism to make it possible to be explicit about which default implementation is used for Y

• Potentially also change the default so that Y gets Q's f() unless the author of Y uses the aforementioned mechanism to make it explicit

The very painful alternative without language changes would be to use composition instead of inheritance (Y holds an X and has all the boilerplate required to select which behaviors it wants from X vs. those it gets via Q or Y).