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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
