Concrete implementation of a generic protocol does not inherit the type aliases from the generic protocol

[coinbump]

Describe the bug
Concrete implementation of a generic protocol does not inherit the type aliases from the generic protocol

Steps To Reproduce

protocol MyThing<First, Second> {
  associatedtype First
  associatedtype Second

  typealias Convenience = (Result<First, Error>) -> Void

  func doSomething(completion: @escaping Convenience)
}

protocol MyMoreConcreteThing: MyThing<String, Int> {
}

class MyConcreteThing: MyMoreConcreteThing {
    var completion: Convenience?

    func doSomething(completion: @escaping Convenience) { // ERROR HERE: Reference to invalid type alias
    }
}

This won't build due to the error: "Reference to invalid type alias 'Convenience' of type 'MyConcreteThing'". However the concrete implementation of the generic protocol should still have access to the generic protocol's type alias.

[AnthonyLatsis]

Reduced:

protocol P {
  associatedtype X = String

  typealias Alias = X

  func foo(_: Alias)
}

struct S: P {
  func bar(_: Alias) {}
  func foo(_: Alias) {}
}

Workaround: transpose S.bar and S.foo (MyConcreteThing.completion and MyConcreteThing.doSomething in the original example).

[slavapestov]

This is yet another manifestation of associated type inference triggering a circular validation.

[AnthonyLatsis]

Yep. The circularity is due to associated type inference relying on the interface types of potential value witnesses. Here’s an even simpler example:

protocol P {
  associatedtype X = Int

  func foo(_: X)
}

struct S: P {
  func bar(_: X) {}
  func foo(_: X) {}
}