<div dir="ltr">On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
> On Nov 28, 2017, at 10:52 AM, Vladimir.S <<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>> wrote:<br>
><br>
> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:<br>
>>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
>>><br>
>>><br>
>>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
>>>><br>
>>>> when SE-185 <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md</a>> went through swift evolution, it was agreed that the next logical step <<a href="https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html</a>> 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 <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md</a>> that tuple comparison is something that makes sense to write.<br>
>>>><br>
>>>> 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.<br>
>>><br>
>>> 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.<br>
>> 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.<br>
><br>
> 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?<br>
> I really believe this is the good practical decision and will be supported by community if such proposal will be on the table.<br>
> Is there any drawback in such step?<br>
<br>
</span>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.<br>
<div class="m_3030071353298663086HOEnZb"><div class="m_3030071353298663086h5"><br>
-Joe<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>i wouldn’t know how to implement this but i could write up this proposal in a few days <br></div></div></div></div></blockquote><div><br></div><div>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!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div></div><br></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>