[swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Félix Cloutier]

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:
"Defining equals with the wrong signature." Impossible in Swift."Changing equals without also changing hashCode." Not addressed by your proposal."Defining equals in terms of mutable fields." Only a problem for reference types, which are not addressed by your proposal."Failing to define equals 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.
I am still far from convinced.
 

    On Tuesday, July 19, 2016 9:53 AM, Johannes Neubauer <neubauer at kingsware.de> wrote:
 

 Dear Félix,

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.

Some literature for you to start with (of course it is not for swift):

* http://www.artima.com/lejava/articles/equality.html(from Martin Odersky et. al. the founder of Scala)
* http://www.angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals.html(from Angelika Langer)
* Book: Effective Java (from Joshua Bloch)
* Book: Java Puzzler  (from Joshua Bloch)
 
> Am 19.07.2016 um 18:00 schrieb Félix Cloutier <felixcca at yahoo.ca>:
> 
> 
>>> This minor enhancement could most likely be obtained by just having a default ==, which is a project that I can get behind.
>> 
>> 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.
> 
> Please do point me to that literature that shows that developers frequently misimplement their own comparators.

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).

> 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.

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.

> 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.

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.

All the best
Johannes


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160719/a018ed1b/attachment.html>