@swift-ci create

It looks to me to be an instance of a problem described here: https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md#overloading-across-constrained-extensions

The bidirection-ness of String gets lost inside the suffix(_: ) overload provided by the extension BidirectionalCollection. Something that needs to be worked around like here, for example,

So if anything, this requires a compiler change. Moving to the Compiler component and /cc @DougGregor and @huonw to maybe explain why this is not going to happen.

The bidirection-ness of String gets lost inside the suffix(_: ) overload provided by the extension BidirectionalCollection. Something that needs to be worked around like here, for example,

I don't think that makes sense as a purposeful choice on our part. The extension BidirectionalCollection as applied to A: BidirectionalCollection should be working with A<...> as an (essentially) opaque entity that is known to conform to BidirectionalCollection, it shouldn't need to be worrying about the type parameter/conditional bounds at all. Thus, this is either a bug in the compiler, or a bug in how suffix (etc.) is written (or both), because this definitely should work! As you say, the code is correctly picking up BidirectionalCollection.suffix, meaning it knows that it’s working with an type that is a bidirectional collection and so that should mean it behaves just like a nonconditionally-conforming type.

Reduced:

public protocol Collection2 {
    // reduced form of: func index(_ i: Index, offsetBy n: Int, limitedBy limit: Index) -> Index?
    func index()
}

extension Collection2 {
    public func index() {
        print("bad")
    }
}

public protocol BidirectionalCollection2: Collection2 {
    // func index()
}

extension BidirectionalCollection2 {
    public func suffix() {
        index()
    }

    public func index() {
        print("good")
    }
}

struct X: BidirectionalCollection2 {}
struct A<C: Collection2>: Collection2 {}
extension A: BidirectionalCollection2 where C: BidirectionalCollection2 {}

A<X>().suffix() // "bad"

One way to work around this is to uncomment the func index() requirement (i.e. add the Collection index(...) requirement to BidirectionalCollection). Another alternative for this specific case in the standard library would be for suffix to call _index instead of index (which is just a public wrapper that dispatches to _index).

I opened #18066 with the latter work-around... whether we want to merge it is up to the stdlib team. I'm personally probably not going to be able to look at the compiler in the near future.

Here's an example demonstrating what's going on here without using constrained extensions. The behavior is expected.

It probably makes sense to emit some kind of warning on the definition of f() in Q since what's happening here is pretty subtle. Having said that, it's not clear how you would silence this warning if you really intend to have a function with the same signature that doesn't have a corresponding requirement in the protocol it is extending (where that requirement exists in one of the protocols this protocol extends).

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()

Relate to new bug for suggested warning: https://bugs.swift.org/browse/SR-8357

It surprises me that this is intended behaviour; is there a reason we're not going to try to make this code work as most people would expect (I would think)?

That could also be incorrect, if X had its own implementation of f that was more specific than either P's or Q's.

@huonw I agree that behavior here is a bit surprising and I am not sure exactly what the reasoning behind this except perhaps that you can only provide default implementations in an extension for the stated requirements of the protocol (as opposed to inherited ones). Perhaps @DougGregor could comment on that?

@belkadan I'm not sure I follow what you're saying, but if you add an implementation to X, we'll call that implementation through dynamic dispatch even if Q has f as a stated requirement.

Sorry, that was my point. It's important that Q's extension call X's implementation of f even if it has its own f around.

We just had a very similar discussion in PR #17995.

@xedin and I were talking with @DougGregor about this and he pointed out an aspect of this that I had overlooked. The reason the `f()` in `Q` isn't called here is actually because of the concrete types involved. Since `X` conforms to `P`, the default implementation in `P` is used in `Y`'s witness for `f`. If you remove that conformance from `X`, then when we produce `Y`'s witness table we find `Q`'s `f()` as a default to fulfill the requirement of `f` on `P`, and end up calling `Q`'s `f()` from `Y().test()`.