SE-0244: Opaque Result Types

[Chris_Lattner3 (Chris Lattner)]

@Paul_Cantrell

The problem is perhaps most obvious in this poetically bollixing error message:

cannot assign value of type '(__opaque opaque.(file).g()@/tmp/opaque.swift:8:6)' to type '(__opaque opaque.(file).f()@/tmp/opaque.swift:4:6)'

I’m sure a release version of the compiler could generate a better error message, but the difficulty of expressing that error well may signal the deeper underlying problem that their anonymity makes these types communication-proof: hard to talk about, hard to think about.

I've mostly stayed out of this thread, but this is exactly my concern. Swift has gone out of its way to have declarations for types (structural types excepted), which is important to the linkage and compilation model, but also the diagnostic and user model. Specifically, it is very problematic to me that these types cannot be named in a natural way, but their identity matters. This is what makes them different than structural types.

@ctxppc

I’m not sure what is a good syntax to express an ORT and an explicit concrete type at the same time but here goes one (straw-man) proposal:

public struct SomeCollection<Element> {
    public opaque typealias FilterCollection = MyFilteringCollection<Element> where FilterCollection : Collection, FilterCollection.Element == Element
    public func filter(where predicate: …) -> FilterCollection {
        …
        return .init(…)    // It works because compiler knows the concrete FilterCollection
    }
}

An (unintended) consequence is that the same opaque type can be used across declarations on the same concrete type. We can forbid this or we can treat them as unequal across uses but I don’t see a problem with allowing multiple declarations to return values that have the same but opaque type to the client. (For API resilience, it wouldn’t be possible to split an opaque typealias into two. Merging should work though.)

I think this approach would be far better: "Opaque type aliases" as a feature seems like it would solve exactly the same set of problems (and the type aliases can have generic constraints already etc) but would provide a name and identity for the type that can be used across declarations within client code. Also, the "future directions" in this proposal seem like they will add a significant amount of language complexity when/if they happened, whereas they would naturally fall out of opaque type aliases.

I'd strongly +1 that direction over the proposal as is.

-Chris