[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types
tony.allevato at gmail.com
Mon Nov 20 20:06:46 CST 2017
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
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.
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <clattner at nondot.org>
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> when SE-185
>> went through swift evolution, it was agreed that the next logical step
>> 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
>> 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”?
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution