<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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)".</div><div class=""><br class=""></div><div class="">What are you trying to protect me from?</div><div class=""><div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 17 juil. 2016 à 06:30:42, Johannes Neubauer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">Am 17.07.2016 um 15:11 schrieb Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>>:<br class=""><br class=""><blockquote type="cite" class="">On Jul 14, 2016, at 1:36 PM, Johannes Neubauer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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?<br class=""></blockquote><br class="">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 <br class=""></blockquote><br class="">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.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Properties pointing at reference types should be tested with `===`.<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">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.<br class=""><br class=""><blockquote type="cite" class="">Ultimately, it boils down to this:<br class=""><br class=""><blockquote type="cite" class="">If a value instance is equal to another, but the value may differ... this is odd semantics.<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">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.<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>