Ever since SE-0185, Swift synthesizes Hashable and Equatable conformances for enums that explicitly declare them, as long as all payload cases are Hashable or Equatable, respectively. However there is an older feature which dates back to Swift 1, where an enum where all cases are empty implicitly gets a Hashable and Equatable conformance, in the obvious way where each case maps to an ordinal.
There is no way to opt out of synthesizing this conformance. This has two downsides:
There is a code size cost; if the enum is public, the optimizer cannot safety strip it out since it might be used from outside the module.
It breaks resilience. In a resilient module, new enum cases can be added to non-frozen enums without breaking ABI. However, if the enum only had empty cases previously, adding a new payload case removes the Hashable conformance, which breaks ABI, unless the new case payload is itself Hashable and the developer explicitly conforms the enum to Hashable. This might not even be possible if, eg, the enum represents error codes, and the new case is an error case with a payload that is not Hashable.
I'm most concerned about the second point. Resilience is not yet a feature in Swift 5, and it's too late in the release cycle anyway, but I'm wondering if the core team would consider taking a proposal to eliminate the implicit conformance synthesis here, even though its a source breaking change.