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.
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@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.
+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.
Specifying 'each' would be optional, it would default to memberResults, or
something equally explicit.
Specifying the protocol is necessary, in case it's not obvious from the
extension.
The function must have the same type, but may take Self for some or all
arguments.
···
On Saturday, 30 January 2016, Dave via swift-evolution < swift-evolution@swift.org> wrote:
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@swift.org <javascript:;>> 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@swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution