> Am 15.07.2016 um 19:05 schrieb Saagar Jha <[email protected]>: > > Equatable, where the == operator is defined, will not let you compare two > things of a different type.
I know that. I mean, this is what I meant with „Swift does a hard job to enforce this“. > On Fri, Jul 15, 2016 at 10:02 Johannes Neubauer <[email protected]> wrote: > > > Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution > > <[email protected]>: > > > > > >> Am 15.07.2016 um 18:29 schrieb Saagar Jha <[email protected]>: > >> > >> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
