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

[Tony Allevato]

On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>

I've been looking the past couple days at how to generalize the protocol
conformance machinery to support structural types (even if we don't support
arbitrary conformance syntactically, at least being able to hardcode the
ones we want to synthesize initially). My free time isn't exactly
plentiful, but I'm hoping to make some decent progress, so I'm happy to
help where I can on this since it's a natural follow-up to my other
Equatable/Hashable work!


>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171129/87a3a8f4/attachment.html>