SE-0215 - Conform Never to Equatable and Hashable

Evolution Proposal Reviews
42

Using an extension of @Chris_Lattner3 's proposal for dynamicCallable SE-0216: User-defined dynamically callable types - #68 by dan-zheng (current proposal doesn't handles static or init), you could make Never conform to all types. For all static and init functions it dispatches to the dynamicallyCallStaticMethod method that throws a fatal error. EG:

@dynamicCallable
struct Never {
  // Catches all `static` and `init` calls.
  @discardableResult
  func dynamicallyCallStaticMethod(withName: String, withArguments: [Any]) -> Never {
    fatalError("`static` function or `init` called on `Never`!")
  }
}
44

You might be interested in reading the proposal that introduced Never and why the name was chosen swift-evolution/0102-noreturn-bottom-type.md at master · apple/swift-evolution · GitHub

1 Like
45

Proposal Accepted

Thank you to everyone who participated in the review of SE-0215. The review discussion was very insightful both on considering the specific problems being addressed by this proposal as well perspective on the role and evolution of the Never type.

The Core Team discussed the review, and reached the following conclusions:

  • The proposal should be accepted with the new explicit conformances to Equatable and Hashable be added to Never. This addresses a real point of friction users are experiencing with the use of Never.

  • For the same reasons conformances to Hashable and Equatable are being added to Never, the Core Team felt that conformances to Error and Comparable should also be added to Never as part of accepting this proposal. Both of these additional protocol conformances were brought up during the review.

  • Never should become a blessed bottom type in the language. This matches with semantics in other languages and its intended role in Swift.

With respect to the latter, the Core Team discussed what Never being a bottom type actually meant. From that discussion we reached the following conclusions:

  • Semantically, as a bottom type, it would mean that Never should be implicitly convertible to any other type. This composes well in the type system because of the fact that instances of Never cannot be instantiated.

  • However, being a bottom type does not imply that Never should implicitly conform to all protocols. Instead, convenient protocol conformances for Never should be added as deemed useful or necessary.

There are various details to suss out with making Never a bottom type, and thus making it a bottom type would be served by a separate and well-considered proposal. It is the opinion of the Core Team that making Never a bottom type would be separate from it conforming to all protocols, and thus the motivation of this particular proposal and the particular problems it addresses stands on its own.

With respect to protocol conformances, the Core Team felt the language has clearly moved in a direction where explicit protocol conformance is fundamental to the language model. The compiler has grown affordances to make the implementation of protocol conformances easy in many cases (e.g., synthesized implementations of Hashable) but that the explicit protocol conformance is quite important. Adding rules for implicit protocol conformances — something that has been considered in Swift’s history — ends up adding real complexity to the language and its implementation that can be hard to reason about by a user as well as by the language implementation.

Thank you again for everyone who participated in this review!

15 Likes