[swift-evolution] [Draft] Hasher & HashVisitable

Joe Groff jgroff at apple.com
Tue Mar 14 12:01:49 CDT 2017


> On Mar 14, 2017, at 10:00 AM, Vladimir.S <svabox at gmail.com> 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
>>> <swift-evolution at swift.org> 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


More information about the swift-evolution mailing list