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

[Andrew Bennett]

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

Perhaps what Dave suggests would work like this:

extension Equatable {
    @memberwise(Equatable, each)
    func ==(lhs: Self, rhs: Self) -> Bool
        return each.reduce(false, each: &&)
    }
}

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 at 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 at 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 at swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160131/030463ae/attachment.html>