[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