Swift regret: no-payload enums implicitly conforming to Hashable— Jordan Rose (@UINT_MIN) October 22, 2021
This was added very early in Swift. Pattern-matching is all well and good, but in ObjC you can compare enums with `==` and we didn’t want to take that away.
Part of the Swift Regrets series.
No-payload enums implicitly conform to Hashable. This was added very early in Swift. Pattern-matching is all well and good, but in Objective-C you can compare enums with
== and we didn’t want to take that away.
This makes a lot more sense if you remember it predates SE-0185. There was no synthesis of Equatable or Hashable for any types. Except no-payload enums. The trouble is, this becomes a source compatibility hazard. If you ever add a payload case to an existing enum, the implicit Hashable conformance disappears. Even if the payload is Hashable. And that’s still true even with SE-0185, because the original feature was implicit.
I think we just didn’t think through how we would want to generalize compiler-derived conformances. Heck, Swift 1 didn’t even have default implementations (no protocol extensions). So there wasn’t much to compare to besides maybe AnyObject. With the benefit of hindsight it’s clear that the compiler should wait for you to write
: Hashable, even for no-payload enums.