The review for SE-0396: "Conform
Never to Codable" ran from April 18 to May 3. The language workgroup has decided to accept the proposal.
Feedback on the proposal was generally positive around the idea of supporting
Codable contexts, with most of the discussion being around specific details of the implementation:
Some commenters asked whether the program should trap instead of throwing an error if it attempts to decode a
Never. The language workgroup feels that the proposal's choice to throw an error is correct because it is not necessarily a logic error to attempt to decode a
Never, especially when decoding occurs in a generic context. Throwing an error ensures that the program has an opportunity to recover from bad external inputs that are not necessarily the fault of the programmer.
A large portion of the discussion on this proposal revolved around the specific error that should be thrown if a program attempted to decode a
Never. The proposal originally stated that
DecodingError.dataCorrupted would be thrown, but many commenters felt that
DecodingError.typeMismatch was a better fit. The author agreed with this feedback and updated the proposal during the review period to use
.typeMismatch instead. The language workgroup also agrees with this change and feels that it provides a better explanation of the error that occurred (including the
Never type in the error message) than
.dataCorrupted, which tends to be used for more general cases of invalid data, such as syntactically malformed JSON.
Some commenters asked whether this behavior should be implemented by having the compiler treat
Never in a special way instead of conforming it to
Codable. The language workgroup believes that this would add unnecessary complexity and would be inconsistent with other conformances. Today in Swift, for example, a type can conform to
Hashable if its component parts are
Hashable, and this includes
Never by virtue of the fact that it conforms to those protocols. Conforming
Codable provides the same behavior for types containing
Never, which is easy to explain and requires no special cases in the compiler.
Thank you to all who participated in the review!
—Tony Allevato, review manager