<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 20, 2017, at 6:07 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This is something I've wanted to look at for a while. A few weeks ago I pushed out <a href="https://github.com/apple/swift/pull/12598" class="">https://github.com/apple/swift/pull/12598</a> to extend the existing synthesis to handle structs/enums when a field/payload has a tuple of things that are Equatable/Hashable, and in that PR it was (rightly) observed, as Chris just did, that making tuples conform to protocols would be a more general solution that solves the same problem you want to solve here.<div class=""><br class=""></div><div class="">I'd love to dig into this more, but last time I experimented with it I got stuck on places where the protocol conformance machinery expects NominalTypeDecls, and I wasn't sure where the right place to hoist that logic up to was (since tuples don't have a corresponding Decl from what I can tell). Any pointers?</div></div></div></blockquote><div><br class=""></div><div>Tuples won’t have a corresponding Decl, because they’re structural. The protocol conformance machinery (e.g., the ConformanceLookupTable) would need to be generalized to cover the various kinds of types that can be made to conform to a protocol: nominal types, function types, tuple types, metatypes, and protocol composition types. Similarly, the assumption that one can only write an extension on a nominal type is fairly widespread in the compiler.</div><div><br class=""></div><div>All of these are fine refactors along the way, and could be used to improve the compiler long before we’re ready to turn it into a user-facing language feature.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">On Nov 20, 2017, at 5:48 PM, Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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 class=""></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">I understand your goal, but that compiler magic can’t exist until there is something to hook it into. Tuples can’t conform to protocols right now, so there is nothing that can be synthesized.</div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">-Chris</div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <span dir="ltr" class=""><<a href="mailto:clattner@nondot.org" target="_blank" class="">clattner@nondot.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_432242003226007445m_2255698535222666290Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">when <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md" target="_blank" class="">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" class="">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" class="">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" class="">SE-15</a> that tuple comparison is something that makes sense to write.<br class=""><br class=""></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 class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">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="m_432242003226007445HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""><br class=""></font></span></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>