<div dir="ltr">so, you want to propose default == operator but not forbidding all peoples to custom == operator?<div><div>Why don't just adding the following function to std library?<br></div><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><span style=""></span><br></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="color:rgb(187,44,162)">public</span><span style=""> </span><span style="color:rgb(187,44,162)">func</span><span style=""> == <T : </span><span style="color:rgb(112,61,170)">Equatable</span><span style="">>(lhs: </span><span style="color:rgb(79,129,135)">T</span><span style="">, rhs: </span><span style="color:rgb(79,129,135)">T</span><span style="">) -> </span><span style="color:rgb(112,61,170)">Bool</span><span style=""> {</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style=""> </span><span style="color:rgb(187,44,162)">var</span><span style=""> lhs = lhs</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style=""> </span><span style="color:rgb(187,44,162)">var</span><span style=""> rhs = rhs</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style=""> </span><span style="color:rgb(187,44,162)">return</span><span style=""> </span><span style="color:rgb(61,29,129)">memcmp</span><span style="">(&lhs, &rhs, </span><span style="color:rgb(61,29,129)">sizeof</span><span style="">(</span><span style="color:rgb(79,129,135)">T</span><span style="">.</span><span style="color:rgb(187,44,162)">self</span><span style="">)) == </span><span style="color:rgb(39,42,216)">0</span></p>
<p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="">}</span></p><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style=""><br></span></p>Thread safety can't fixed by std library. Value type only can atomic compared when additional mutex provided.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-16 19:50 GMT+08:00 Johannes Neubauer <span dir="ltr"><<a href="mailto:neubauer@kingsware.de" target="_blank">neubauer@kingsware.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Susan,<br>
<br>
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:<br>
<br>
```swift<br>
func ==(lhs: A, rhs: B) {<br>
if(globalBooleanVarIsDayEven) {<br>
return false<br>
}<br>
// do a normal check<br>
}<br>
```<br>
<br>
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.<br>
<br>
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:<br>
<br>
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.<br>
<br>
[0]: <a href="http://devstreaming.apple.com/videos/wwdc/2016/720w6g8t9zhd23va0ai/720/720_concurrent_programming_with_gcd_in_swift_3.pdf" rel="noreferrer" target="_blank">http://devstreaming.apple.com/videos/wwdc/2016/720w6g8t9zhd23va0ai/720/720_concurrent_programming_with_gcd_in_swift_3.pdf</a></blockquote></div><br></div>