+1. It seems like a practical first step.
> On Nov 28, 2017, at 10:59 AM, Joe Groff via swift-evolution > <[email protected]> wrote: > > > >> 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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
