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

[Johannes Neubauer]

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