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.
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. -Shawn On Fri, Jul 15, 2016 at 8:37 AM Tino Heth via swift-evolution < [email protected]> wrote: > Hello Johannes, > > > Am 14.07.2016 um 22:36 schrieb Johannes Neubauer via swift-evolution < > [email protected]>: > > > > 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? > > 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: > 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). > > 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 ;-) > > Best regards, > Tino > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
