+1 on this proposal. It would also be nice to have this on Comparable, @memberwise would be a useful way to do it. I think how member wise could be defined needs work.<div><br></div><div>Perhaps what Dave suggests would work like this:</div><div><br></div><div>extension Equatable {</div><div>    @memberwise(Equatable, each)</div><div>    func ==(lhs: Self, rhs: Self) -&gt; Bool</div><div>        return each.reduce(false, each: &amp;&amp;)</div><div>    }</div><div>}</div><div><br></div><div>Specifying &#39;each&#39; would be optional, it would default to memberResults, or something equally explicit.</div><div><br></div><div>Specifying the protocol is necessary, in case it&#39;s not obvious from the extension.</div><div><br></div>The function must have the same type, but may take Self for some or all arguments.<br><div><br></div><div><div>On Saturday, 30 January 2016, Dave via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the memberwise op would have to return an array of results. For ops where it’s obvious how to reduce the array (like ==), it seems like a protocol extension or something could automatically do the “.reduce(true) { $0 &amp;&amp; $1 }” part, and when the final answer isn’t so obvious, you could either provide the args for reduce(), or just call it yourself (maybe… depends on how it’s implemented).<br>
<br>
I have absolutely no ideas regarding syntax.<br>
<br>
&gt; On Jan 30, 2016, at 01:41, Jan E. Schotsman via swift-evolution &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; I would like some more discussion of the proposal for a default memberwise equality function for compound types.<br>
&gt;<br>
&gt; It was suggested that some stored properties might be excluded from the comparison for equality.<br>
&gt; Also calculated properties might be included (presumably if at least two stored properties are excluded).<br>
&gt; Wouldn’t this complicate things too much (requiring two keywords?)<br>
&gt; If only 9 properties  out of 10 are equatable should equality be based on that? What about 5 in 10?<br>
&gt;<br>
&gt; Generalisation of the mechanism (applying a protocol to aggregates of types satisfying the protocol) was suggested using a ‘memberwise’ annotation of the protocol.<br>
&gt; Even in case of simple protocols like Equatable, SignedIntegerType this requires a specific implementation.<br>
&gt; In case of Equatable the memberwise comparison results must be “anded”, for SignedIntegerType  the IntMax initializer must be replaced by a tuple.<br>
&gt; IMHO in case of custom protocols it is unlikely that the compiler can guess (or be instructed in a simple way to provide) the intended implementation.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;swift-evolution@swift.org&#39;)">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>