[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma]

On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> > On Nov 28, 2017, at 10:52 AM, Vladimir.S <svabox at gmail.com> 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 <
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>>
> >>>
> >>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
> swift-evolution at swift.org <mailto:swift-evolution at 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.
> >> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

i wouldn’t know how to implement this but i could write up this proposal in
a few days
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171128/93f01e28/attachment.html>