+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) -> Bool</div><div> return each.reduce(false, each: &&)</div><div> }</div><div>}</div><div><br></div><div>Specifying 'each' 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'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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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 && $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>
> On Jan 30, 2016, at 01:41, Jan E. Schotsman via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I would like some more discussion of the proposal for a default memberwise equality function for compound types.<br>
><br>
> It was suggested that some stored properties might be excluded from the comparison for equality.<br>
> Also calculated properties might be included (presumably if at least two stored properties are excluded).<br>
> Wouldn’t this complicate things too much (requiring two keywords?)<br>
> If only 9 properties out of 10 are equatable should equality be based on that? What about 5 in 10?<br>
><br>
> Generalisation of the mechanism (applying a protocol to aggregates of types satisfying the protocol) was suggested using a ‘memberwise’ annotation of the protocol.<br>
> Even in case of simple protocols like Equatable, SignedIntegerType this requires a specific implementation.<br>
> In case of Equatable the memberwise comparison results must be “anded”, for SignedIntegerType the IntMax initializer must be replaced by a tuple.<br>
> 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>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">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>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">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>