Derive Equatable & Hashable for uninhabited types

[mdiep]

The original proposal did explicitly say this wouldn't be done:

The compiler does not synthesize P's requirements for an enum with no cases because it is not possible to create instances of such types.

But I'm hoping that this change doesn't need to go through the evolution process:

1. This is clearly possible

2. It's useful when your enum is part of a larger protocol, you expect it to gain cases, or you're using it with generics.

I've been running into this a lot at work. It's often confusing for people to figure out why these aren't derived and what they should do about it.

[rudkx]

@mdiep Given that it's specifically called out in the original proposal I think it would make sense to ping the Evolution Discussion and ask for guidance. If this does get merged with should amend the original proposal in some fashion to indicate the change.

[xwu]

Since we don't have special treatment for Never, with all behaviors applying equally to all uninhabited types, isn't SE-0215 effectively calling for all uninhabited types to conform to Hashable and Equatable?

[jrose-apple]

1. No, SE-0215 as written is still just proposing that Never conform to those two protocols, presumably explicitly.
2. SE-0215 may not pass, so this is still relevant. (I agree with Mark that it does need guidance, though.)

[mdiep]

No, SE-0215 as written is still just proposing that Never conform to those two protocols, presumably explicitly.

Right. This might change the implementation of SE-0215, but is a separate question.

SE-0215 may not pass, so this is still relevant. (I agree with Mark that it does need guidance, though.)

I've started a discussion.

[allevato]

To briefly repeat what I said in my reply on the forum, I'm in support this. The limitation was arbitrary in retrospect because it seemed "natural", but the generic use cases shown in the discussion thread are convincing. Thanks, Matt!

[mdiep]

The discussion has received positive feedback from core members and no negative feedback. I think that means this can proceed?

[rudkx]

@swift-ci Please smoke test

[mdiep]

bump

[jrose-apple]

There's a conflict now, so you'll have to fix that before we can merge.

[mdiep]

There's a conflict now, so you'll have to fix that before we can merge.

Sorry, I didn't see that on my phone. 🙈 I've rebased and fixed the conflicts.

[jrose-apple]

@swift-ci Please smoke test

[mdiep]

bump

[mdiep]

I'd like to get this in 4.2 if possible. Should I just cherry-pick and open a PR against the 4.2 branch?

[jrose-apple]

Yep, then include all the information in https://swift.org/blog/4-2-release-process/#pull-requests-for-release-branch and assign it to Ted.