[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu]

Agree: I think it’s painfully obvious that we want tuples to conform to
Equatable under the appropriate circumstances. Whether this is magic or not
is not strictly settled (though I agree with Kelvin that magic is sensible
here), but right now the issue is that tuples can’t conform to protocols at
all and they very much need to be able to—but how?

On Mon, Nov 20, 2017 at 20:51 Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
>
> the end goal here is to use tuples as a compatible currency type, to that
> end it makes sense for these three protocols to be handled as “compiler
> magic” and to disallow users from manually defining tuple conformances
> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
> Comparable are special because they’re the basis for a lot of standard
> library functionality so i think the benefits of making this a special
> supported case outweigh the additional language opacity.
>
>
> I understand your goal, but that compiler magic can’t exist until there is
> something to hook it into.  Tuples can’t conform to protocols right now, so
> there is nothing that can be synthesized.
>
> -Chris
>
>
>
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <clattner at nondot.org>
> wrote:
>
>>
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> when SE-185
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
>> went through swift evolution, it was agreed that the next logical step
>> <https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html>
>> is synthesizing these conformances for tuple types, though it was left out
>> of the original proposal to avoid mission creep. I think now is the time to
>> start thinking about this. i’m also tacking on Comparable to the other
>> two protocols because there is precedent in the language from SE-15
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
>> that tuple comparison is something that makes sense to write.
>>
>> EHC conformance is even more important for tuples than it is for structs
>> because tuples effectively have no workaround whereas in structs, you could
>> just manually implement the conformance.
>>
>>
>> In my opinion, you’re approaching this from the wrong direction.  The
>> fundamental problem here is that tuples can’t conform to a protocol.  If
>> they could, synthesizing these conformances would be straight-forward.
>>
>> If you’re interested in pushing this forward, the discussion is “how do
>> non-nominal types like tuples and functions conform to protocols”?
>>
>> -Chris
>>
>>
>>
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171121/f593a3ca/attachment.html>