The vast majority of situations where I've wanted to use opaque types in Swift (outside of SwiftUI) have involved sequences or collections, so I'm very positive on this proposal even though it doesn't bring that to the standard library yet—getting closer is still important. I'll avoid restating smaller concerns that others have already expressed in the thread (like @jrose's above, which I agree with).
One small tooling-related concern: AFAIK, type parameters can't be documented today aside from free-standing prose in the description of the type. Since an associatedtype is its own declaration that can host a doc comment, moving an associatedtype into a primary type list means there's nowhere to hang that documentation anymore (e.g., Sequence.Element).
It would be great if something like the following, which doesn't work today, could be supported:
/// A type that provides sequential, iterated access to its elements.
///
/// - Parameter Element: A type representing the sequence’s elements.
public protocol Sequence<Element> {
// ...
}
If Parameter feels like the wrong tag to use here, I'm not picky about the name—it would just be nice to make sure these can still be documented in a structured manner (and, while outside the scope of this proposal, extend this to concrete generic types as well).