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@swift.org> wrote: > On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin1...@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 <clatt...@nondot.org> > wrote: > >> >> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution < >> swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution