[swift-evolution] [proposal] default func ==(_:_:)

davesweeris at mac.com davesweeris at mac.com
Sat Jan 30 04:27:09 CST 2016

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).

I have absolutely no ideas regarding syntax.

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

More information about the swift-evolution mailing list