<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=""><div><blockquote type="cite" class=""><div class="">On Nov 9, 2017, at 4:29 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Why not? Specifically, why shouldn't we require `Hashable` conformance on indices? Adding it would require changes to conforming types, sure, but indices are already required to be `Equatable`, and `Hashable` conformance just got really easy to add, and custom `Collection`s are a relatively rare and advanced feature.</blockquote><div dir="auto" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div dir="auto" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">For a source-breaking change, that’s the wrong question to ask. It’s not “why not,” but “why so”? It’s so easy to add the conformance, and any type can opt into it so easily, what is the gain by forcing it and can it be justified as a source-breaking change?</div></div></blockquote></div><div class=""><br class=""></div><div class="">You're right that source-breaking changes need to be justified. What I would say is:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. This proposal as written will require many conditional conformances; it would be better (and would allow us to fully implement it sooner) if they were unconditional.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2. Relying on `where` clauses does not help you in type-erased code. `AnyIndex` cannot conditionally conform to `Hashable` because it erases types, and it's not clear to me whether `AnyIndex` can be cleanly converted to `AnyHashable` or vice versa. This means code using type erasure may be awkward to write if it needs `Hashable` indices.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>3. The `KeyPath` case discussed in this proposal is another example where ad-hoc `Hashable` indices cause trouble for type erasure (in that `KeyPath`s erase the types of the indices inside them). It would be very weird for `KeyPath`s to only support indices if they happen to also be `Hashable`.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>4. `Hashable` conformance is extremely useful in general. It allows, among other features, use as a `Set` or `Dictionary` key, and apparently now use in `KeyPath` as well. Replacing an `Array` of indices with a `Set`, or switching from some other representation to a `KeyPath`, is the sort of change we would like generic algorithms to be able to make without breaking binary compatibility with their callers.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>5. `Hashable` occupies a special place of importance among our standard protocols. In the past, we've occasionally discussed making it mandatory and impossible to opt out of; many languages actually do that. Even though we haven't, I've seen experts make flat statements along the lines of "All value types should conform to `Hashable`". This is not like requiring an index to be, say, `Strideable` or a `SignedInteger`.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>6. The compiler can now automatically synthesize `Hashable` conformance for many simple types; this makes the burden of requiring a conformance unusually low.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>7. I have written several custom collections, and it has never occurred to me to conform the index to `Hashable`, but now that it's been mentioned I realize that it would have been both easy and extremely useful to do so. My index types would already have been `Hashable` if the standard library had forced me to do so.</div><div class=""><br class=""></div><div class="">Basically, what it comes down to is, `Hashable` is very useful and there are not many plausible index designs which would have trouble supporting it. It is not absolutely necessary to make this change, but I think it would lead to better, more useful types with a fairly low burden.</div><div class=""><br class=""></div><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></body></html>