> 1. You cannot say something is unequal although the system says it is equal
That doesn't make me feel much safer. Comparison returned false when it should have returned true? Step into, see why it happened. Sounds like your garden variety of bugs. The downside is that every comparison now starts with an equality comparison of every field, which is not obvious (you can't step into invisible behavior), and does more work than necessary. > 2. You do not have to implement equality for value types, only if you really > need custom behavior (so you do not write boiler-plate code, which is error > prone), so side effects will be less common I think that a default == for structs that only have Equatable fields makes sense and I can get behind that. We don't need the rest to implement this, though. > 3. With unique indirect storage (and copy-on-write) you would be able use > `==` for large values, because these values are only shared for reads not for > writes (future, not yet available in swift), so no race conditions This is hypothetical and in advance of Swift's concurrency model. > 4. With `dispatch` in operator-methods (or any other) as well as a `default` > clause for reference types, so that equality of mixed-types just result in > `false`, so that this is not possible anymore (see excerpt of discussion): If I understand the suggested dispatch keyword correctly, it could only work if executables carried metadata for every method, which would be a size concern (especially on size-constrained platforms like Apple Watch) and make reverse engineering about as easy as it is in the Objective-C world. We had an improvement here and this would roll it back. You are imposing the costs not just upon yourself, but upon everybody, on every platform, on every project, forever. Would it be a web app or an operating system component, the only way to opt out is to stop using the default equality and fragment the way that you do comparison. Are you really that confident that this will make everyone happier, now and in the future, than the model that we currently have? Please realize that this is an absolutely radical change. Swift currently has little to no invisible behavior, and currently lets you implement equality any way that you like. In my book, radical changes should be considered with extreme skepticism, and should have an extremely compelling case behind them. Félix _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
