> I haven't had the > chance to consider all the implications yet, but—at least until someone > can demonstrate that we really custom == for classes—we should be open > to the idea as we consider the value semantics story.
I've been lurking and skimming the discussion around this so far, but I'll speak up at this point. I really do think making `==` always be an identity check for class types is not a realistic option. What you're proposing is essentially what Objective-C does. When Swift was introduced, the ability to use operators like `==` to mean *logical* equality instead of *referential* equality was touted as a major advantage. And it *is* a major advantage for readability—`text1 == text2` (where text1 and text2 are, say, NSMutableString or NSAttributedString) is much nicer than `text1.isEqual(text2)`. We would be giving up a significant feature of the language for a vision of purity that most programmers don't (think they) care about. Now, one thing you *could* do is allow overloading of `==` and instead take `===` for this purpose. `===` is already an identity check on reference types and unavailable on value types; for value types, it could be defined as always equivalent to `==`. This would leave `==` open to user definition on class types, while exposing your value equality operation as `===`. Either way, though, if `Hashable` is always identity-based on class types, that will cause bridging issues. NSDictionary and Dictionary (or NSSet and Set) will no longer agree on which objects are distinct and which are not. Converting from the Swift type to the Foundation type and back again may lose elements. If we broaden `===` to all instances, `Hashable` will probably still need to be tied to `==`, not `===`. It's unfortunate that those darned users are always getting in the way of our elegant designs. :^) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
