Swift 5.7 compiler bug? Known limitation? My mistake?

This looks to me like a Swift 5.7 compiler bug, but if I'm just doing something wrong that would be preferable. Any help is much appreciated:

var bar: some A<Int> {
    foo().flatten // Error: Return type of var 'bar' requires that '(some A).B' conform to 'Int'
func foo () -> some A<X<Int>> {
extension A where B: A {
    var flatten: some A<B.B> {
struct X <B>: A {}
protocol A <B> {
    associatedtype B

I've also noticed some cases where nested primary associated types are dropped, and I don't know what relevant is being worked on.

This makes your code compile:

extension A where B: A<Int> {

…but is that going to scale for you in the short term?

I believe this is Bug with opaque result type substitutions · Issue #60430 · apple/swift · GitHub. I found the bug last month while writing some documentation about the generics implementation. Unfortunately, it looks like you discovered the same problem before I was able to fix it (or finish writing the documentation...)


It's pretty ok for now - it means that in each importing module I need to paste a set of overloads for each of that modules types that I may want to pass around optionals of, which is a bit of a burden, but if I know that maybe by Swift 5.8(?) it's likely that @Slava_Pestov will have come to the rescue and the bug fix is included then I can happily paste those overloads for now and keep them in one file per module and delete them all when the bug is fixed. Slava, do you have any sense of the difficulty and/or potential timeline of fixing it?


I'd like to fix it soon now that it's actually been reported in the wild.

In the mean time, there is another simple but non-obvious workaround. The problem is the return type some A<B.B>. The type B.B is actually Self.B.B, which is a type parameter of length 3. If you can think of a way to change it to a type parameter of length 2 (Self.X for some new associated type X which is equivalent to Self.B.B via some set of requirements) then it would fix your problem.

Nice! I removed the where constraint on the extension and instead added a generic parameter <Wrapped> to the function along with where Value == Optional<Wrapped>, which is nice both because it fixed the error and because it avoids using the protocol OptionalProtocol that I have defined and retroactively conformed Optional to so as to be able to use it in generic constraints.


Issues like these remind me that I'm so glad you in particular are working on this area! Been following and loving your work (which of course depends on the rest of a great team).