Your initial rationale no longer makes sense with your suggested solution. If the dumb comparison returns false, people can still introduce side effects in the comparison method, except that now it's even harder to find out because all of my equality tests have been rewritten as "memcmp(a, b) || ==(a, b)".
What are you trying to protect me from? Félix > Le 17 juil. 2016 à 06:30:42, Johannes Neubauer via swift-evolution > <swift-evolution@swift.org> a écrit : > > >> Am 17.07.2016 um 15:11 schrieb Brent Royal-Gordon <br...@architechies.com>: >> >>> On Jul 14, 2016, at 1:36 PM, Johannes Neubauer via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> 1. Custom implementation of equals operator `==` for value types should be >>> forbidden. Rationale: Why has it been added in the first place? For >>> omitting some values from the equals test? >> >> This limitation would prevent you from even implementing IEEE floating-point >> semantics (+0.0 == -0.0, while NaN != NaN; neither would be allowed by this >> rule). It would similarly prevent you from implementing even moderately > > Didn’t you follow the correspondence of these proposals? There are corner > cases (like this one above), but there should be a default equality check and > you shouldn’t be able to decide, that something is not equal, which the > default equality check says that it is equal. In addition, you mention basic > types of the swift language. Of course their have to be some axioms in the > language which have to be created by the language designers. Floating-point > semantics fall exactly into this category. > >>> Properties pointing at reference types should be tested with `===`. >> >> This rule in particular would also prevent you from implementing Equatable >> semantics for most of the copy-on-write containers (String, Array, Set, >> Dictionary), which all use an internal reference to a memory buffer. And >> several of Foundation's struct wrappers, like the `Data` type that wraps >> `NSData`. And any value type of your own which contains a lot of internal >> data and which, after a lot of testing and benchmarking, you determine would >> be more efficiently implemented as a value type wrapping a reference type >> with copy-on-write semantics. And who knows what else. > > Please, you should really follow the discussion here. I already lined out all > these cases. I wrote this before Arnold from apple told me that some blog > posts out there are wrong about how value types work internally. This is > something that can be done in the future, as soon as swift has something like > automatic indirect storage with a unique value pool and with copy-on-write > semantics for „large“ value types. > >> Ultimately, it boils down to this: >> >>> If a value instance is equal to another, but the value may differ... this >>> is odd semantics. >> >> Equality is how we define whether two instances differ: If `==` returns >> `true`, then they don't differ. Now, there are some important commonsense >> rules about this—two `==` instances should have virtually identical >> behavior—but you can't just ignore the widespread need for this feature. If >> Swift didn't offer `Equatable` overloading, we would have to invent it >> ourselves—most likely with some sort of half-baked workaround that would >> cause confusion about whether you ought to use "pure" equality or "smart" >> equality in any given situation. Think of the `==` vs. `===` mess in >> JavaScript and you'll get an idea of what I mean. > > Really, please read especially my last mails. My proposal does not prevent > you from doing this differentiation directly in the language, but prevents > you from doing some nasty bugs. > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
