Sent from my iPad
> On Nov 9, 2017, at 6:29 AM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Thu, Nov 9, 2017 at 05:28 Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> wrote: >> > >> > https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md >> > >> > • What is your evaluation of the proposal? >> >> This all seems very sensible, but here's my big question: >> >> AnyIndex, which type erases any index type at run-time, would not be >> hashable since it might wrap a non-hashable type. >> >> 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. > > 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? 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. > >> >> 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. >> >> > • Is the problem being addressed significant enough to warrant a change to >> > Swift? >> >> Yes. >> >> > • Does this proposal fit well with the feel and direction of Swift? >> >> Yes. >> >> > • If you have used other languages or libraries with a similar feature, >> > how do you feel that this proposal compares to those? >> >> N/A. >> >> > • How much effort did you put into your review? A glance, a quick reading, >> > or an in-depth study? >> >> Quick reading, nothing more. >> >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
