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
EquatableandHashablebe added toNever. This addresses a real point of friction users are experiencing with the use ofNever. -
For the same reasons conformances to
HashableandEquatableare being added toNever, the Core Team felt that conformances toErrorandComparableshould also be added toNeveras part of accepting this proposal. Both of these additional protocol conformances were brought up during the review. -
Nevershould 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
Nevershould be implicitly convertible to any other type. This composes well in the type system because of the fact that instances ofNevercannot be instantiated. -
However, being a bottom type does not imply that
Nevershould implicitly conform to all protocols. Instead, convenient protocol conformances forNevershould 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!