[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 Susan,

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