> On Mar 14, 2017, at 10:00 AM, Vladimir.S <[email protected]> wrote: > > On 14.03.2017 18:34, Joe Groff via swift-evolution wrote: >> >>> On Mar 13, 2017, at 10:54 AM, Sean Heber via swift-evolution >>> <[email protected]> wrote: >>> >>> I’m dumb when it comes to proper hashing, but it’s such a tediously >>> common thing in my experience to need to add Hashable to some kind of >>> a struct so I can stash it in a set or use it as a dictionary key. Is >>> there really no way to make this all more automatic? I have to be >>> honest - this proposal seems *harder* to understand than the way it >>> works now. Of course the easiest would be if the language could just >>> do this “good enough" for me using reflection or whatever and if I >>> really did run into a problem where I wanted to do this myself, I >>> could override something. >>> >>> Perfect is the enemy of good. >> >> The compiler totally ought to derive reasonable default Equatable and >> Hashable implementations for you. That would allow the standard library >> to do the right thing without burdening most users with the need to >> sweat the details. > > I believe many of us dream of an feature of auto-generated Equatable and > Hashable implementations. > > Btw, what is your opinion, can we expect (at some point of time) > Equatable&Hashable for tuples? > It is very handy to have Dictionary<Tuple<type1,type2>, type3> in C# and sad > that we can't have [(type1,type2):type3] in Swift without declaration of new > temporary struct type and implement Equatable&Hashable for it.
It would be reasonable, IMO, even before we support the full generalization of extensions on non-nominal types, to make tuples of Equatable/Hashable/Comparable elements conform to the same protocols by fiat. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
