<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><div id="AppleMailSignature">Sent from my iPad</div><div><br>On Nov 9, 2017, at 6:29 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div><br><div class="gmail_quote"><div dir="auto">On Thu, Nov 9, 2017 at 05:28 Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md</a><br>
><br>
> • What is your evaluation of the proposal?<br>
<br>
This all seems very sensible, but here's my big question:<br>
<br>
AnyIndex, which type erases any index type at run-time, would not be hashable since it might wrap a non-hashable type.<br>
<br>
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"><br></div><div dir="auto">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></div></div></blockquote><div><br></div><div>In this case we’re talking about the requirements on indices when ABI stability happens. That’s a pretty important point of design to get right. I think Brent *is* asking the right question in this case. I haven’t given it enough thought to form a clear opinion as to the answer yet.</div><br><blockquote type="cite"><div><div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is it worth a source break to add it? Personally, I think so—but even if you disagree, I think we should document why we decided not to add it.<br>
<br>
> • Is the problem being addressed significant enough to warrant a change to Swift?<br>
<br>
Yes.<br>
<br>
> • Does this proposal fit well with the feel and direction of Swift?<br>
<br>
Yes.<br>
<br>
> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
<br>
N/A.<br>
<br>
> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
Quick reading, nothing more.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<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><br>
</blockquote></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>