[swift-evolution] [Draft] Hasher & HashVisitable

[Jaden Geller]

If this were desired, an associated type would not be sufficient. Perhaps `Dictionary` only supports keys where `Hash == Int`. Then any type that might key a dictionary must use `Int` as it’s hash type. It wouldn’t be possible to define a second implementation with `Int128` or any other types as the hash type since each type can only conform to a protocol once.

Now, if we had generic protocols, this would be possible…

extension Foo: Hashable<Int> { … }
extension Foo: Hashable<Int128> { … }

I’m not sure if that would even be a reasonable design though; I’m just pointing out that the associated type would be problematic.

Cheers,
Jaden Geller

> On Mar 14, 2017, at 4:45 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It would be possible for a Hasher to return varying types, but then people might want the interface to support cryptographic hashing as well as variable length hashes (for things like HAMT)
> 
> -DW
> 
>> On Mar 14, 2017, at 4:56 PM, Greg Parker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Mar 14, 2017, at 12:01 PM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Are we committed to having `hashValue` always be an `Int`, or could it be an associated type like  `(Int, Int, Int, Int)`? Seems like especially for something like a BigNum type or an Array, there might simple not be a reasonably efficient way to uniquely-ish represent 1024 bits with just 64 bits.
>>> 
>>> (This kinda feels like one of those questions where the answer starts out with a variation on “you’re missing the point”)
>> 
>> This would lead to an implementation nightmare for hashing containers. Consider what the implementation of Dictionary<Any, String> would look like if any of its keys could have incompatible hash outputs.
>> 
>> 
>> -- 
>> Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20170314/b7042c04/attachment.html>