[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]

In order to prevent false-negatives for reference types, I would like to add a 5th. point to my proposals:

5. Identity (i.e. `===`) should be checked even for reference types upfront and only if it returns `false` the custom `==` function of the developer is executed. This way you cannot implement an equals operator, that says two objects are **not** equal although they are the very same instance.


> Am 16.07.2016 um 13:50 schrieb Johannes Neubauer via swift-evolution <swift-evolution at swift.org>:
> 
> I wrote the former mail in a hurry: the URI example from before is a *false-positive* either and can be handled like the `Polar` example. But the problem with false-negatives are still valid. Example:
> 
> ```swift
> func ==(lhs: A, rhs: B) {
>  if(globalBooleanVarIsDayEven) {
>    return false
>  }
>  // do a normal check
> }
> ```
> 
> This would not be possible, if you check for equality upfront and omitting executing the custom code above if the standard check returns `true` already.
> 
> Another **big** problem with using `==` for properties to reference types implementing `Equatable` is race conditions and as Matt Wright pointed out in his talk [Concurrent Programming with GCD in Swift 3][0] on WWDC 2016, there are no harmless cases of concurrency issues. Rationale:
> 
> Reference types share state possible with code that runs concurrently in different threads. So if you compare via `==` to value types and use `==` to compare the object(s) of a reference type property this object(s) may change during the check (even if the machine has only one core, if the OS is preemptive). And this may happen even if it is the very same (by identity and `===`) object that is referenced. A (future) automatic value pool for indirect storage with copy-on-write for value semantics would not share this problem, of course, since their storage is only shared for reads and not for writes (the `===` check on this indirect storage would by definition suffice and be much faster than executing the check). This does not hold for properties of references types in that indirect storage.
> 
> [0]: http://devstreaming.apple.com/videos/wwdc/2016/720w6g8t9zhd23va0ai/720/720_concurrent_programming_with_gcd_in_swift_3.pdf