This works (as in, fails to compile with a vaguely reasonable error message) without the conformance:

struct Generic<Foo, Bar> {}
extension Generic where Foo == Int {
    typealias X = Foo
}
extension Generic where Foo == Bar {
    typealias Y = Foo
}
print(Generic<String, Bool>.X.self) 
print(Generic<String, Bool>.Y.self) 

sr7976.swift:8:7: error: 'Generic<String, Bool>.X.Type' (aka 'Int.Type') requires the types 'String' and 'Int' be equivalent
print(Generic<String, Bool>.X.self)
      ^
sr7976.swift:9:7: error: 'Generic<String, Bool>.Y.Type' (aka 'String.Type') requires the types 'String' and 'Bool' be equivalent
print(Generic<String, Bool>.Y.self)
      ^

@swift-ci create

@huonw for some reason your code does compile without an error in Swift playground and prints `Int` and `String`. Anyway your first error message seems to be wrong. The constraint for `X` to be a member of `Generic` does not require `Foo == Bar` but only `Foo == Int`.

Edit: Sorry I misunderstood the error message, it's correct.

Could this be related to SR-5440?

Ah, great catch. I was using the master branch, and it seems like the typealias case/SR-5440 was recently (mostly) fixed (in d573309 specifically), but associated types seem to not have been covered by that.

Then maybe this is related to SR-7605 too? And maybe it's also affecting generic type parameters as in the example of my comment there?

#17168 fixes this when the types are used in expressions, but there's no error if they're used in decls, e.g. let _: Generic<String, Bool>.Foo instead of the print.

It could very well be related to SR-7605, and the fix for this might fix that one too, but associated type inference is a complicated beast at the moment, so I would (unfortunately) guess it won't be quite that simple.

OK, thanks!

Both of these rightly raise errors with the latest snapshot, in expression and type identifier positions.

Fixed by Slava alongside SR-5440