[swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Shawn Erickson]

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 <
swift-evolution at swift.org> wrote:

> Hello Johannes,
>
> > Am 14.07.2016 um 22:36 schrieb Johannes Neubauer via swift-evolution <
> swift-evolution at swift.org>:
> >
> > 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160715/d9b997ff/attachment.html>