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

[Susan Cheng]

so, you want to propose default == operator but not forbidding all peoples
to custom == operator?
Why don't just adding the following function to std library?


public func == <T : Equatable>(lhs: T, rhs: T) -> Bool {

    var lhs = lhs

    var rhs = rhs

    return memcmp(&lhs, &rhs, sizeof(T.self)) == 0

}


Thread safety can't fixed by std library. Value type only can atomic
compared when additional mutex provided.

2016-07-16 19:50 GMT+08:00 Johannes Neubauer <neubauer at kingsware.de>:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160718/2b423744/attachment.html>