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

[Tony Allevato]

This is something I've wanted to look at for a while. A few weeks ago I
pushed out https://github.com/apple/swift/pull/12598 to extend the existing
synthesis to handle structs/enums when a field/payload has a tuple of
things that are Equatable/Hashable, and in that PR it was (rightly)
observed, as Chris just did, that making tuples conform to protocols would
be a more general solution that solves the same problem you want to solve
here.

I'd love to dig into this more, but last time I experimented with it I got
stuck on places where the protocol conformance machinery expects
NominalTypeDecls, and I wasn't sure where the right place to hoist that
logic up to was (since tuples don't have a corresponding Decl from what I
can tell). Any pointers?

On Mon, Nov 20, 2017 at 5:51 PM 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/94de85df/attachment.html>