<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If this were desired, an associated type would not be sufficient. Perhaps `Dictionary` only supports keys where `Hash == Int`. Then any type that might key a dictionary must use `Int` as it’s hash type. It wouldn’t be possible to define a second implementation with `Int128` or any other types as the hash type since each type can only conform to a protocol once.<div class=""><br class=""></div><div class="">Now, if we had generic protocols, this would be possible…</div><div class=""><br class=""></div><div class="">extension Foo: Hashable&lt;Int&gt; { … }</div><div class="">extension Foo: Hashable&lt;Int128&gt; { … }</div><div class=""><br class=""></div><div class="">I’m not sure if that would even be a reasonable design though; I’m just pointing out that the associated type would be problematic.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Jaden Geller</div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2017, at 4:45 PM, David Waite via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">It would be possible for a Hasher to return varying types, but then people might want the interface to support cryptographic hashing as well as variable length hashes (for things like HAMT)<div class=""><br class=""><div class="">-DW</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 14, 2017, at 4:56 PM, Greg Parker via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 14, 2017, at 12:01 PM, David Sweeris via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">Are we committed to having `hashValue` always be an `Int`, or could it be an associated type like &nbsp;`(Int, Int, Int, Int)`? Seems like especially for something like a BigNum type or an Array, there might simple not be a reasonably efficient way to uniquely-ish represent 1024 bits with just 64 bits.</div><div class=""><br class=""></div><div class="">(This kinda feels like one of those questions where the answer starts out with a variation on “you’re missing the point”)</div></div></div></blockquote><br class=""></div><div class="">This would lead to an implementation nightmare for hashing containers. Consider what the implementation of Dictionary&lt;Any, String&gt; would look like if any of its keys could have incompatible hash outputs.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">--&nbsp;</div><div class="">Greg Parker &nbsp; &nbsp; <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a>&nbsp; &nbsp; &nbsp;Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></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=""></div></div></body></html>