In theory, `Never` can be a substitute for every type, since you have no instance to call any methods on, but that breaks down with static methods since those don’t need an instance. Right, the issue is with static and initializer requirements. The `Never` type itself can be a subtype of all types in the language but that does not mean that `Never` can conform to all protocols. So, it gets hairy when you introduce generalized existentials into the language. i.e. `Never` needs to be a subtype of those existentials without necessarily conforming to the protocol. Related, SE-0217: https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/222

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

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

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/XXXX-function-builders.md at 9992cf3c11c2d5e0ea20bee98657d93902d5b174 · apple...

Right now, if you want to abstract the return type of a declaration from its signature, existentials or manual type erasure are your only options, and these come with tradeoffs that are not always acceptable. Instead of declaring the specific return type of `EightPointedStar.shape`'s current implementation, all we really want to say is that it returns something that conforms to `Shape`. We propose the syntax `some Protocol`. An opaque return type can be thought of as putting the generic signature “to the right” of the function arrow; instead of being a type chosen by the caller that the callee sees as abstracted, the return type is chosen by the callee, and comes back to the caller as abstracted. or some composition thereof (joined with `&`)

The `Box`, `Lazy`, `UserDefault`, and `Clamping` examples are worth reviewing. Composition of wrappers is right-associative.

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.

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0192-non-exhaustive-enums.md at main · apple/swift-evolution