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

[Saagar Jha]

Equatable, where the == operator is defined, will not let you compare two
things of a different type.
On Fri, Jul 15, 2016 at 10:02 Johannes Neubauer <neubauer at kingsware.de>
wrote:

>
> > Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution <
> swift-evolution at swift.org>:
> >
> >
> >> Am 15.07.2016 um 18:29 schrieb Saagar Jha <saagarjha28 at gmail.com>:
> >>
> >> Here's a value type that uses custom equality (at least, I think so):
> String. Since it uses extended grapheme clusters, internally two Strings
> may be composed of different Unicode scalars, but if they create the same
> Characters they are considered to be equal.
> >
> > Good point. But shouldn’t this be another type of equality then or do
> they behave exactly the same and are just implemented differently? Because
> if not, this seems to be introducing mixed-type comparisons like `5l == 5`
> or `Point2D(0, 0) == Point3D(0, 0, 0) which are bad since they make it
> impossible to guarantee reflexivity, symmetry, and transitivity. Swift does
> a hard job to enforce this from the programmer. If this is really intended,
> then there should be a fixed implementation for equality of value types,
> which can be overridden, but which leads to a warning (which has to be
> suppressed with some kind of annotation or so). Because, these custom
> implementations can do harm.
>
> And I would do the „standard equality“ upfront even if there is a custom
> implementation and if the „standard equality“ says `true`, the custom
> implementation is not asked. This would reduce the possibility of
> false-negatives.
>
-- 
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160715/c02371ee/attachment.html>