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).

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/proposals/0244-opaque-result-types.md at b1caeccf5d273a1cc53b331d41ea169f7729...

it’s reassuring to know that the folks driving changes in Swift have a solid background in language design, and that they’re thinking about all manner of hard problems in order to make our lives easier. However, it makes me worry that people might be missing out on a truly exciting conversation about what might be coming in a future Swift version. The reason for the label “reverse generics” is that the flow of information is backwards from the existing system. Where right now, the caller binds generic types as it calls a function, the proposal would have the function itself bind the return types and pass concrete values back out.

Hi all, I wrote an Automatic Differentiation Manifesto, as the start to push for world's first general-purpose differentiable programming language.