> Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution > <swift-evolution@swift.org>: > > >> Am 15.07.2016 um 18:29 schrieb Saagar Jha <saagarjh...@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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
