> On 15 Mar 2017, at 01:10, Jaden Geller via swift-evolution 
> <[email protected]> wrote:
> 
> 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

I believe the associated type would be on the Hasher in that case (not the 
Hashee, which just feeds it bytes). So if the Hasher was a generic parameter on 
Dictionary with suitable default, its keys would all produce values of the same 
type anyway. The “hashValue” property could be defined as having to return a 
word-sized hash; if you override it and use your own “standard hasher” for a 
particular type, you would have to compact it in to an Int somehow.

The big problem with making Dictionary<K, V> in to Dictionary<K, V, H> is that 
from an API perspective, almost nobody who uses a Dictionary cares about the 
hashing function being used. We could solve this by allowing partially-bound 
generic types (e.g. Dictionary<K, V, _>) and either define a typealias, or 
formalise the notion of a private/optional generic type parameter which does 
not affect a type’s API and is never required to be specified. Alternatively, 
we could refactor Dictionary’s implementation as SecureDictionary<K, V, H> and 
keep Dictionary<K, V> as a wrapper (with the obvious caveat that your custom 
dictionaries won’t work with most other library code).

- Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to