Conform Never to Error, Equatable, Comparable, and Hashable #16857
Conversation
stdlib/public/core/Policy.swift
Outdated
| @@ -28,6 +28,18 @@ | |||
| @_frozen | |||
| public enum Never {} | |||
|
|
|||
| extension Never: Equatable { | |||
| public static func == (lhs: Never, rhs: Never) -> Bool { | |||
| switch (lhs, rhs) { | |||
There was a problem hiding this comment.
This is cute but I would really rather this be spelled out.
There was a problem hiding this comment.
I’m not sure what you mean. 😕
There was a problem hiding this comment.
The switch is required by the compiler right now, no?
There was a problem hiding this comment.
return true rather than the switch.
There was a problem hiding this comment.
Oh, ha. Even did that here: https://github.com/pointfreeco/swift-prelude/blob/master/Sources/Prelude/Equatable.swift#L3 I suppose the switch is only required for absurd.
There was a problem hiding this comment.
I think switch is the better option.
return true is a bit misleading. It's easy to continue thinking that this code could possibly execute. (fatalError("This is impossible. A Never value cannot be constructed") would be better in this regard.)
switch educates the reader about Never and about switch. I think this works as a form of progressive disclosure. You don't need to know that this how it's implemented, but if you go looking, most people are bound to learn something.
I think the swift-evolution discussion bears this out. Several people expressed confusion initially, but walked away with a better understanding.
There was a problem hiding this comment.
If the goal is pedagogy uber alles, the switch, being needlessly clever, cuts the wrong way. I dont buy the progressive disclosure angle because the most disclosure you get as a consumer of the stdlib is the protocol conformance. As a part of the stdlib, especially as a particularly opaque part of the stdlib, this conformance needs to be optimized for readability and maintenance.
So we’re in an odd position here because anything meant to convey a message at runtime like a fatalError will never happen and is dead weight both literally and semantically. Ultimately, whatever the community settles on, please document this well.
|
@swift-ci build toolchain |
|
Linux Toolchain (Ubuntu 16.04) Install command |
|
macOS Toolchain Install command |
|
Updated swift-ci comment with correct download links. |
|
@swift-ci build toolchain |
|
Linux Toolchain (Ubuntu 16.04) Install command |
|
macOS Toolchain Install command |
|
@swift-ci test |
|
@mdiep: This proposal has been accepted. Per the acceptance rationale please also add conformances to |
|
Build failed |
mdiep
force-pushed
the
conform-never-to-equatable-and-hashable
branch
from
9a8da86 to
4c415b8
Compare
mdiep
changed the title
|
How does that look? |
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
|
Can we add some form of test? The usual |
mdiep
force-pushed
the
conform-never-to-equatable-and-hashable
branch
from
4c415b8 to
e0dae8e
Compare
|
How does that test look? |
|
WFM! |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
CI pick up the wrong SHA for some reason. 😕 It should be testing e0dae8e. |
|
It's a bug with the Jenkins/GitHub integration after a force push. We have it set up to automatically restart and test the correct commit when this happens. |
|
Can this be merged? 🙂 |
|
Could this be included in 4.2? Or would that pose a potential source compatibility problem? (I'm happy to open a PR. I just don't want to waste any effort.) |
|
Probably not at this stage. We’re trying to keep it at just bug fixes. |
Implementation for swiftlang/swift-evolution#855.