<div style="white-space:pre-wrap">Additional two "things" maybe considered equal in the chosen problem domain despite their identity (memory location, etc.) being different. Having the ability to supply custom hash and equality for types can be a useful tool in a developers toolbox. For example two pathways of code may create what is actually the same thing (say a reference to the same file on disk) then want to work with stdlib set and/or dictionary with the equivalent things being resolved correctly, etc.<br><br>To remove custom equality will limit some designs and to force identity based equality with present similar problems on the other end of the spectrum.</div><div style="white-space:pre-wrap"><br><br>-Shawn</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 15, 2016 at 8:37 AM Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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">Hello Johannes,<br>
<br>
> Am 14.07.2016 um 22:36 schrieb Johannes Neubauer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
><br>
> 1. Custom implementation of equals operator `==` for value types should be forbidden. Rationale: Why has it been added in the first place? For omitting some values from the equals test?<br>
<br>
It would be nice to have an easy way to conform to Hashable & Equatable without writing much boilerplate (it's possible in other existing languages), but I see no motivation to forbid custom implementations — not only because you are free to stay away from those, but also because there can be good reasons to do so:<br>
Equality isn't always as simple as it seems, and many developers have been bitten by issues with floating point types… instead of "a == b", often "abs(a - b) < delta" is the right choice, and a custom "==" is the only option to specify delta (given a situation where you are comparing float-members of a struct).<br>
<br>
For the other three points, I'd suggest to present each of them later in separate threads — it's already hard to follow each topic, and it would be even harder when there are three different proposals in a single thread ;-)<br>
<br>
Best regards,<br>
Tino<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>