[swift-evolution] Equatable auto-write func == Proposal

[Francisco Costa]

+1 for making enums with payloads Equatable by default. Right now this
requires lots of copy-paste boiler plate that can easily result in bugs.

As for the general struct case, I think there could be a default
implementation but we should be able to overwrite `==` if we need to.
Doesn't seem sensible to me comparing several inner objects and arrays if a
single `uuid` would suffice.

Francisco


On Mon, Sep 19, 2016 at 3:15 PM, Jérôme Duquennoy via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi guys,
>
> It would be awesome if with this evolution, we could also auto-write
> equality operators for enum with equatable payloads.
>
> Today, considering this enum
>
> enum SimpleEnum {
>   case case1
>   case case2
> }
>
> the condition SimpleEnum.case1 == SimpleEnum.case1 compiles and return
> true.
>
> But if the enum has a payload
>
> enum EnumWithPayload {
>   case integer(value: Int)
>   case float(value: Float)
> }
>
> the condition EnumWithPayload.integer(value: 1) == EnumWithPayload.integer(value:
> 1) does not compile: operator == does not exist for that type.
>
> Hand-writing this missing equality operator turns out to be pretty
> fastidious and error prone, notably because you might prefer to not use a
> “default” case, to take advantage of the completeness check of the compiler.
> So you have to write n * (n-1) cases and that can be a lot of cases !
>
> Jerome
>
> > Good point.
> >
> > The real push here is that when the programmer *does* declare a type
> Equatable and the op == has an obvious implementation, that the programmer
> shouldn’t have to manually implement it him/herself. This would apply only
> to types that have been declared Equatable and that consist of exclusively
> properties which have all also been declared Equatable.
> >
> > This would work much like the Haskell Eq class.
> >
> > > On Sep 12, 2016, at 12:03 PM, Robert Widmann<devteam.codafi at
> gmail.com>wrote:
> > >
> > > Please be careful when wording this proposal. You want derived
> conformances, but don't obscure that message with the claim that every type
> admits a useful Equatable instance. It is most certainly not the case that
> every value type has a useful (read [mostly]: decidable) equality. A few
> counterexamples, the type of lazy streams (https://github.com/typelift/
> Swiftz/blob/swift-develop/Swiftz/Stream.swift#L24<https:
> //github.com/typelift/Swiftz/blob/swift-develop/Swiftz/Stream.swift#L24>)
> requires infinite space to evaluate a useful answer. The type of functions
> [without a modulus of continuity] also don't admit a useful, or even
> canonical, equality (in Swift at least).
> > >
> > > ~Robert Widmann
> > >
> > > 2016/09/10 8:24、Daniel Tartaglia via swift-evolution<swift-evolution
> at swift.org<mailto:swift-evolution at swift.org>>のメッセージ:
> > >
> > > > Now that Swift 3 is out the door, I’m going to float this proposal
> again…
> > > >
> > > > Given that every value type should be equatable (rational here):
> https://www.andrewcbancroft.com/2015/07/01/every-swift-
> value-type-should-be-equatable/<https://www.andrewcbancroft.com/2015/07/
> 01/every-swift-value-type-should-be-equatable/>
> > > > And that many, if not most, value types consist of properties that
> are value types.
> > > > Then the language should make it easy to conform to the Equatable
> protocol.
> > > >
> > > > In other words, if I declare my value type as Equatable, and it is
> exclusively composed of value types that are already equatable, then
> implementing the actual == function should be optional (or maybe even
> forbidden.)
> > > >
> > > > Implementing == in such cases is tedious boilerplate that the
> compiler should be able to infer on its own.
> > > >
> > > > Does anybody want to help me write up an official proposal?
> >
> >
> >
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160926/bc9d32a1/attachment.html>