On Nov 20, 2017, at 6:30 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org> wrote: > > can we go the route of SE-15 and just synthesize up to some sensible n = 7 or > whatever. i feel like this list has a habit of going “but it would be a lot > better to add X if we just wait until Y is a thing first” ignoring that Y > will probably not be a thing for the forseeable future and we really need X > right now
Sure, you can generate implementations of == or hashing functions, but that won’t let you use them as the key to a dictionary. For that, you need actual conformance. -Chris > > On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Ignoring synthesized conformances for a second, think about how you would > manually implement a conformance of a tuple type to a protocol. You would > need some way to statically “iterate” over all the component types of the > tuple — in fact this is the same as having variadic generics. > > If we had variadic generics, we could implement tuples conforming to > protocols, either by refactoring the compiler to allow conforming types to be > non-nominal, or by reworking things so that a tuple is a nominal type with a > single variadic generic parameter. > > Slava > > >> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 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 >> <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 <mailto:swift-evolution@swift.org>> wrote: >> On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin1...@gmail.com >> <mailto: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 >>> <mailto:clatt...@nondot.org>> wrote: >>> >>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution >>>> <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > 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
