[swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[T.J. Usiyan]

+1 to a `deriving` keyword

On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution <
swift-evolution at swift.org> wrote:

> Can we just copy&paste the solution from Haskell instead of creating our
> own? It's just better in every aspect. Deriving `Equatable` and `Hashable`
> would become
>
> struct Polygon deriving Equatable, Hashable {
>     ...
> }
>
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason),
> you can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any
> new incompatibilities. For example, `CustomStringConvertible` could be
> derived just as easily.
> - It is compatible with generics. E.g. `struct Shape<T> deriving
> Equatable` will make every `Shape<X>` equatable if `X` is equatable. But if
> `X` is not equatable, `Shape<X>` can be used as well. (Unless `X` is not
> used, in which case every `Shape<T>` would be equatable. Unless something
> in the definition of `Shape` makes deriving `Equatable` impossible => this
> produces an error.)
> - It is proven to work in production.
>
> -Michael
>
> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution <
> swift-evolution at swift.org>:
> >
> > Thanks so much for putting this together, Tony! Glad I was able to be
> some inspiration. :^)
> >
> >
> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
> > I was inspired to put together a draft proposal based on an older
> discussion in the Universal Equality, Hashability, and Comparability thread
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/8919/> that
> recently got necromanced (thanks Mark Sands!).
> >
> > I'm guessing that this would be a significant enough change that it's
> not possible for the Swift 3 timeline, but it's something that would
> benefit enough people that I want to make sure the discussion stays alive.
> If there are enough good feelings about it, I'll move it from my gist into
> an actual proposal PR.
> >
> > Automatically deriving Equatable andHashable for value types
> >
> >       • Proposal: SE-0000
> >       • Author(s): Tony Allevato
> >       • Status: Awaiting review
> >       • Review manager: TBD
> > Introduction
> >
> > Value types are prevalent throughout the Swift language, and we
> encourage developers to think in those terms when writing their own types.
> Frequently, developers find themselves writing large amounts of boilerplate
> code to support equatability and hashability of value types. This proposal
> offers a way for the compiler to automatically derive conformance
> toEquatable and Hashable to reduce this boilerplate, in a subset of
> scenarios where generating the correct implementation is likely to be
> possible.
> >
> > Swift-evolution thread: Universal Equatability, Hashability, and
> Comparability
> >
> > Motivation
> >
> > Building robust value types in Swift can involve writing significant
> boilerplate code to support concepts of hashability and equatability.
> Equality is pervasive across many value types, and for each one users must
> implement the == operator such that it performs a fairly rote memberwise
> equality test. As an example, an equality test for a struct looks fairly
> uninteresting:
> >
> > func ==(lhs: Foo, rhs: Foo) -> Bool
> >  {
> >
> > return lhs.property1 == rhs.property1 &&
> >
> >          lhs
> > .property2 == rhs.property2 &&
> >
> >          lhs
> > .property3 == rhs.property3 &&
> >
> >
> > ...
> >
> > }
> >
> > What's worse is that this operator must be updated if any properties are
> added, removed, or changed, and since it must be manually written, it's
> possible to get it wrong, either by omission or typographical error.
> >
> > Likewise, hashability is necessary when one wishes to store a value type
> in a Set or use one as a multi-valuedDictionary key. Writing high-quality,
> well-distributed hash functions is not trivial so developers may not put a
> great deal of thought into them – especially as the number of properties
> increases – not realizing that their performance could potentially suffer
> as a result. And as with equality, writing it manually means there is the
> potential to get it wrong.
> >
> > In particular, the code that must be written to implement equality for
> enums is quite verbose. One such real-world example (source):
> >
> > func ==(lhs: HandRank, rhs: HandRank) -> Bool
> >  {
> >
> > switch
> >  (lhs, rhs) {
> >
> > case (.straightFlush(let lRank, let lSuit), .straightFlush(let rRank ,
> let
> >  rSuit)):
> >
> > return lRank == rRank && lSuit ==
> >  rSuit
> >
> > case (.fourOfAKind(four: let lFour), .fourOfAKind(four: let
> >  rFour)):
> >
> > return lFour ==
> >  rFour
> >
> > case (.fullHouse(three: let lThree), .fullHouse(three: let
> >  rThree)):
> >
> > return lThree ==
> >  rThree
> >
> > case (.flush(let lRank, let lSuit), .flush(let rRank, let
> >  rSuit)):
> >
> > return lSuit == rSuit && lRank ==
> >  rRank
> >
> > case (.straight(high: let lRank), .straight(high: let
> >  rRank)):
> >
> > return lRank ==
> >  rRank
> >
> > case (.threeOfAKind(three: let lRank), .threeOfAKind(three: let
> >  rRank)):
> >
> > return lRank ==
> >  rRank
> >
> > case (.twoPair(high: let lHigh, low: let lLow, highCard: let
> >  lCard),
> >
> > .twoPair(high: let rHigh, low: let rLow, highCard: let
> >  rCard)):
> >
> > return lHigh == rHigh && lLow == rLow && lCard ==
> >  rCard
> >
> > case (.onePair(let lPairRank, card1: let lCard1, card2: let lCard2,
> card3: let
> >  lCard3),
> >
> > .onePair(let rPairRank, card1: let rCard1, card2: let rCard2, card3: let
> >  rCard3)):
> >
> > return lPairRank == rPairRank && lCard1 == rCard1 && lCard2 == rCard2 &&
> lCard3 ==
> >  rCard3
> >
> > case (.highCard(let lCard), .highCard(let
> >  rCard)):
> >
> > return lCard ==
> >  rCard
> >
> > default
> > :
> >
> > return false
> >
> >   }
> > }
> >
> > Crafting a high-quality hash function for this enum would be similarly
> inconvenient to write, involving another large switchstatement.
> >
> > Swift already provides implicit protocol conformance in some cases;
> notably, enums with raw values conform toRawRepresentable, Equatable, and
> Hashable without the user explicitly declaring them:
> >
> > enum Foo: Int
> >  {
> >
> > case one = 1
> >
> >
> > case two = 2
> >
> > }
> >
> >
> > let x = (Foo.one == Foo.two)  // works
> > let y = Foo.one.hashValue     // also works
> > let z = Foo.one.rawValue      // also also works
> > Since there is precedent for this in Swift, we propose extending this
> support to more value types.
> >
> > Proposed solution
> >
> > We propose that a value type be Equatable/Hashable if all of its members
> are Equatable/Hashable, with the result for the outer type being composed
> from its members.
> >
> > Specifically, we propose the following rules for deriving Equatable:
> >
> >       • A struct implicitly conforms to Equatable if all of its fields
> are of types that conform to Equatable – either explicitly, or implicitly
> by the application of these rules. The compiler will generate an
> implementation of ==(lhs: T, rhs: T)that returns true if and only if lhs.x
> == rhs.x for all fields x in T.
> >
> >       • An enum implicitly conforms to Equatable if all of its
> associated values across all of its cases are of types that conform to
> Equatable – either explicitly, or implicitly by the application of these
> rules. The compiler will generate an implementation of ==(lhs: T, rhs: T)
> that returns true if and only if lhs and rhs are the same case and have
> payloads that are memberwise-equal.
> >
> > Likewise, we propose the following rules for deriving Hashable:
> >
> >       • A struct implicitly conforms to Hashable if all of its fields
> are of types that conform to Hashable – either explicitly, or implicitly by
> the application of these rules. The compiler will generate an
> implementation of hashValue that uses a pre-defined hash function† to
> compute the hash value of the struct from the hash values of its members.
> >
> > Since order of the terms affects the hash value computation, we
> recommend ordering the terms in member definition order.
> >
> >       • An enum implicitly conforms to Hashable if all of its associated
> values across all of its cases are of types that conform to Hashable –
> either explicitly, or implicitly by the application of these rules. The
> compiler will generate an implementation of hashValue that uses a
> pre-defined hash function† to compute the hash value of an enum value by
> using the case's ordinal (i.e., definition order) followed by the hash
> values of its associated values as its terms, also in definition order.
> >
> > † We leave the exact definition of the hash function unspecified here; a
> multiplicative hash function such as Kernighan and Ritchie or Bernstein is
> easy to implement, but we do not rule out other possibilities.
> >
> > Overriding defaults
> >
> > Any user-provided implementations of == or hashValue should override the
> default implementations that would be provided by the compiler. This is
> already possible today with raw-value enums so the same behavior should be
> extended to other value types that are made to implicitly conform to these
> protocols.
> >
> > Open questions
> >
> > Omission of fields from generated computations
> >
> > Should it be possible to easily omit certain properties from
> automatically generated equality tests or hash value computation? This
> could be valuable, for example, if a property is merely used as an internal
> cache and does not actually contribute to the "value" of the instance.
> Under the rules above, if this cached value was equatable, a user would
> have to override == and hashValue and provide their own implementations to
> ignore it. If there is significant evidence that this pattern is common and
> useful, we could consider adding a custom attribute, such as @transient,
> that would omit the property from the generated computations.
> >
> > Explicit or implicit derivation
> >
> > As with raw-value enums today, should the derived conformance be
> completely explicit, or should users have to explicitly list conformance
> with Equatable and Hashable in order for the compiler to generate the
> derived implementation?
> >
> > Impact on existing code
> >
> > This change will have no impact on existing code because it is purely
> additive. Value types that already provide custom implementations of == or
> hashValue but satisfy the rules above would keep the custom implementation
> because it would override the compiler-provided default.
> >
> > Alternatives considered
> >
> > The original discussion thread also included Comparable as a candidate
> for automatic generation. Unlike equatability and hashability, however,
> comparability requires an ordering among the members being compared.
> Automatically using the definition order here might be too surprising for
> users, but worse, it also means that reordering properties in the source
> code changes the code's behavior at runtime. (This is true for hashability
> as well if a multiplicative hash function is used, but hash values are not
> intended to be persistent and reordering the terms does not produce a
> significant behavioral change.)
> >
> > Acknowledgments
> >
> > Thanks to Joe Groff for spinning off the original discussion thread,
> Jose Cheyo Jimenez for providing great real-world examples of boilerplate
> needed to support equatability for some value types, and to Mark Sands for
> necromancing the swift-evolution thread that convinced me to write this up.
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20160526/ef9a258b/attachment.html>