<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12px"><div id="yui_3_16_0_ym19_1_1468963494033_4135">Allow me to reciprocate the feeling. Java equality isn't particularly relevant to Swift equality, and the majority of issues are already solved. Here's a breakdown of the first link that you posted:</div><div id="yui_3_16_0_ym19_1_1468963494033_4663"><br></div><div id="yui_3_16_0_ym19_1_1468963494033_4446" dir="ltr">"Defining <code id="yui_3_16_0_ym19_1_1468963494033_4493">equals</code> with the wrong signature." Impossible in Swift.</div><div id="yui_3_16_0_ym19_1_1468963494033_4695" dir="ltr">"Changing <code id="yui_3_16_0_ym19_1_1468963494033_4553">equals</code> without also changing <code id="yui_3_16_0_ym19_1_1468963494033_4554">hashCode.</code>" Not addressed by your proposal.</div><div id="yui_3_16_0_ym19_1_1468963494033_4692" dir="ltr">"Defining <code id="yui_3_16_0_ym19_1_1468963494033_4614">equals</code> in terms of mutable fields." Only a problem for reference types, which are not addressed by your proposal.</div><div id="yui_3_16_0_ym19_1_1468963494033_4693" dir="ltr">"Failing to define <code id="yui_3_16_0_ym19_1_1468963494033_4666">equals</code> as an equivalence relation." The only one which your proposal for structure types actually addresses, and I am skeptical that it needs as much attention as it does in Java.</div><div dir="ltr"><br></div><div dir="ltr">I am still far from convinced.</div><div id="yui_3_16_0_ym19_1_1468963494033_5301" dir="ltr"><br></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> On Tuesday, July 19, 2016 9:53 AM, Johannes Neubauer <neubauer@kingsware.de> wrote:<br></font></div> <br><br> <div class="y_msg_container">Dear Félix,<br clear="none"><br clear="none">We just disagree here and I am confident you are wrong, but I will bring this topic up again in August after Swift 3 has been released.<br clear="none"><br clear="none">Some literature for you to start with (of course it is not for swift):<br clear="none"><br clear="none">* <a href="http://www.artima.com/lejava/articles/equality.html" target="_blank" shape="rect">http://www.artima.com/lejava/articles/equality.html</a>(from Martin Odersky et. al. the founder of Scala)<br clear="none">* <a href="http://www.angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals.html" target="_blank" shape="rect">http://www.angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals.html</a>(from Angelika Langer)<br clear="none">* Book: Effective Java (from Joshua Bloch)<br clear="none">* Book: Java Puzzler (from Joshua Bloch)<br clear="none"> <br clear="none">> Am 19.07.2016 um 18:00 schrieb Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" shape="rect" ymailto="mailto:felixcca@yahoo.ca">felixcca@yahoo.ca</a>>:<br clear="none">> <br clear="none">> <br clear="none">>>> This minor enhancement could most likely be obtained by just having a default ==, which is a project that I can get behind.<br clear="none">>> <br clear="none">>> Structs do not have a common ancestor, this is why swift uses existential containers, in order to create polymorphic behavior for protocol types with value type implementations. So implementing such a default == would bring changes to swift either. But I didn’t bring this idea in the first place to have some more convenience. I am sure (and literature as well as my experience as a developer and project lead in many industrial projects proves me right), that implementing equality is a major source of errors in software development and I think that you underestimate this issue.<br clear="none">> <br clear="none">> Please do point me to that literature that shows that developers frequently misimplement their own comparators.<br clear="none"><br clear="none">See above. We are talking about equality (Equatable) not about comparison (i.e. Comparable or in mathematics <=), so the example literature is about the former (although implementing Comparable is error-prone, too).<br clear="none"><br clear="none">> No, they can't. There is no way to differentiate a char array that should be a null-terminated string from a char array that is actually a byte array at the C level.<br clear="none"><br clear="none">There is a feature/paradigm/whatever called in-/outboxing and coercing. On that level of abstraction (as long as you know what is underlying and for C structs the default is null-termination) you can just decide, which comparison should be used… if not, you couldn’t call `size` or `length` on them, too.<div class="yqt2471781371" id="yqtfd18134"><br clear="none"><br clear="none">> This sounds like piling on more work for the sake of it. If we end up forcing a default equality check on everything, I hope that we can at least rely on it being there all the time, because otherwise that will also be a bug vector.</div><br clear="none"><br clear="none">It would be part of the compiler, that is as if you would question whether an instance is created when you call the constructor. You have to trust the compiler to some extend.<br clear="none"><br clear="none">All the best<br clear="none">Johannes<div class="yqt2471781371" id="yqtfd25019"><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>