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
> <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Mar 14, 2017, at 12:01 PM, David Sweeris via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]> Runtime
>> Wrangler
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
