> On Nov 28, 2017, at 10:52 AM, Vladimir.S <[email protected]> wrote: > > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution >>>> <[email protected] <mailto:[email protected]>> 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/[email protected]/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. >> It would be a tractable intermediate problem to introduce built-in >> conformances for tuples (and perhaps metatypes) to >> Equatable/Hashable/Comparable without breaching the more general topic of >> allowing these types to have general protocol conformances. I think that >> would cover the highest-value use cases. > > So, shouldn't we do this first step ASAP and then design a good common > solution to allow tuples/metatypes/funcs to confirm to custom protocols in > some next version of Swift? > I really believe this is the good practical decision and will be supported by > community if such proposal will be on the table. > Is there any drawback in such step?
The expected behavior of tuple Equatable/Hashable/Comparable seems obvious to me (though I could well be missing something), and any behavior we hardcode should be naturally replaceable by a generalized conformance mechanism, so it's primarily a "small matter of implementation". There would be some implementation cost to managing the special case in the compiler and runtime; the tradeoff seems worth it to me in this case, but others might reasonably disagree. Not speaking for the entire core team, I would personally support considering a proposal and implementation for builtin tuple Equatable/Hashable/Comparable conformance. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
