Thanks for writing this up. This is pretty much what we had in mind for opaque typealiases as well. However, by declaring Rust's impl Trait irrelevant, I'm afraid you're missing some of the point of this feature. I understand the uncomfortableness about anonymous types, and the desire to plan for the general case. However, Rust's impl Trait design is the strongest prior art I know of for a feature like this, and Rust programmers use the feature heavily in both user and library code, and these issues as far as I can tell are simply not a problem in practice; I've asked. Doug and I did our homework here; we thoroughly explored the idea of typealiases before writing up this proposal, and found them wanting for a number of reasons:
- They lose one of the primary benefits of the Rust feature, which is the ability to directly describe a function's return interface without the indirection of another name. Furthermore, this feature is competing directly with existential types in that "hide the concrete return type" role; we know existentials are inadequate in that role for all the reasons the proposal outlines, but if it takes a second decl, a restatement of the concrete underlying type, and coming up with a new name to take advantage of opaque types, then existentials will still look syntactically attractive as an alternative.
- Opaque type aliases introduce new design and implementation complications, since the relationship between the opaque and underlying type becomes visible across multiple declarations; naively representing this as a bidirectional implicit conversion in the type checker would be bad for performance and predictability. Implementing any sort of "these types are sometimes the same, sometimes different" feature is quite difficult once you get into the details. Furthermore, because an opaque type alias is an independent decl, returning an opaque typealias would lose the ability for a function to use a nested type to completely hide its implementation type.
- Opaque type aliases don't make the "where clause" problem any easier in the general case.
Looking at the bigger picture, we're also trying to lay groundwork for other language improvements that don't have anything directly to do with return types. The "anonymous type" design problem still exists in the language at large and influence the design of other future language features like generalized existentials. We also foresee the sugar syntax being useful as a shorthand for generic arguments. We'll likely need a more expressive syntax for describing constraints on anonymous types for generalized existentials, and the sugar syntax we're proposing has a useful generalization, we're aiming for something that achieves the most important subset of abstracting return types while planning for a syntactic analogy with generalized existentials and clearer overall generics notation going forward.