<div dir="ltr">the end goal here is to use tuples as a compatible currency type, to that end it makes sense for these three protocols to be handled as “compiler magic” and to disallow users from manually defining tuple conformances themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and Comparable are special because they’re the basis for a lot of standard library functionality so i think the benefits of making this a special supported case outweigh the additional language opacity.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_2255698535222666290Apple-interchange-newline"><div><div dir="ltr"><div><div>when <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md" target="_blank">SE-185</a> went through swift evolution, it was agreed that the <a href="https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html" target="_blank">next logical step</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 <span style="font-family:monospace,monospace">Comparable</span> to the other two protocols because there is precedent in the language from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md" target="_blank">SE-15</a> that tuple comparison is something that makes sense to write.<br><br></div>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. </div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>If you’re interested in pushing this forward, the discussion is “how do non-nominal types like tuples and functions conform to protocols”?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div><div><br></div><br><br></font></span></div><br></div></blockquote></div><br></div>