We could think of type-level-abstracted return types as doing the same thing but at the type level; you give a function generic arguments as inputs, and it gives a certain return type back. ​ This roughly follows the progression of `impl Trait` in Rust, where it was first introduced only for return types, then was generalized to be able to appear structurally in both argument and return types. We think this is a reasonable first step because it directly addresses the biggest functionality gap in the generics model. After that first step, there are a few fairly orthogonal language change discussions we can have, some of which are already underway

Whenever I mentally parse `protocol SomeProtocol: SomeOtherProtocol`, it’s meant to imply `SomeProtocol` adds additional requirements onto another protocol, namely `SomeOtherProtocol`’s. What’s odd about class-constraining protocols is that it’s been a weird historical inconsistency in Swift where the term to the right of the `:` _isn’t_ a protocol and instead a reserved word. All reference types implicitly conform to `AnyObject`, which, being a protocol, makes it a more consistent way of class constraining than remembering the special `: class` trick. This merging of concepts was lightly mentioned in [SE-0156](https://github.com/apple/swift-evolution/blame/93abb54833e2d9ee7ee842882f6104a867de3069/proposals/0156-subclass-existentials.md#L134) (link to specific line).