In #3, #4, and #5, you're trying to differentiate them from a subset of their properties that CustomHashable can see. It sounds a lot more like Identifiable than Hashable, and that pattern probably works better (Identifiable has associated type, so we won't be using it):
protocol KitchenItem {
var name: String { get }
}
private struct ID: Hashable {
var name: String
}
extension KitchenItem {
var id: some Hashable {
ID(name: name) // Or just use `name` if there's one field.
}
}
struct IdentifiedKitchenItem: Hashable {
var item: KitchenItem
public func hash(into hasher: inout Hasher) { item.id.hash(into: &hasher) }
public static func ==(lhs: Self, rhs: Self) -> Bool { lhs.item.id == rhs.item.id }
}
which would run into the question I asked earlier:
and I'll just assume the answer is yes.
For #1 and #2, well, it's an extremely risky business to provide Hashable implementation for types that you only partially know. If you insist, however, you can use the good'ol trick:
This would be preferred over synthesized Hashable implementation (red flag!), and it would use only id to differentiate between two instances (red flag!).
They shouldn't be. Here is another bit of my old examples with made-up syntax from above replies.
let mainStageTonight =
Set<MusicPerformer & Comparable..?>([FreddieMerqurie(), JimmyHendrix()])
//can store any musician whose performance quality can be compared
protocol MusicPerformer: Comparable {
var crowdExcitement: Int { Int.random(in: 0..<9) }
func singASong() { print("...doing some performance...") }
func < (lhs: MusicPerformer, rhs: MusicPerformer) -> Bool {
if lhs.crowdExcitement < rhs.crowdExcitement { return true }
if lhs.crowdExcitement > rhs.crowdExcitement { return false }
}
}
struct FreddieMerqurie: MusicPerformer, Comparable {
func singASong() { print("You have been rocked!") }
let crowdExcitement: Int
let wasOnDrugs: Bool
func < (...) ...
}
struct JimmyHendrix: MusicPerformer, Comparable {
func singASong() { print("Such powerful riffs!") }
let crowdExcitement = 10
let whatever: ...
func < (...) ...
}
//this means that even though FreddieMerqurie and JimmyHendrix are
//different things, they still can be compared on how they do music
//while FreddieMerqurie's and JimmyHendrix's can have different measurements
//when comparing to themselves
//but there is a critical difference:
//while these musicians should be compared with identical standards
//(should be compared as MusicPerformer s)
//they also should expose unique singing
for performer in mainStageTonight { performer.singASong() } //You have been rocked etc
//whist
mainStageTonight.max() //shoud compare them as MusicPerformer s
Well, uhm, kinda, buuuut.... adapters, man! . They are boilerplate and does not compose well, for every combination of some traits, codebase would be bloated. I was baited by Protocol-oriented programming, sigh.
I admit that I've not been able to follow exactly what you want to accomplish, but it seems that you want hashability to mean different things at different times for the same entities, all using the same protocol.
Protocols are not intended to be bags of syntax. If you need different ways of hashing the same type, you need a separate protocol per semantic.
Besides for the technical issues, I'm really struggling to understand why you'd want to write such impenetrable code in the first place.
Not for same entities: I want to have the ability to express different hashing for a concrete type and its existential type. For ex
protocol A: Hashable { //default impl here }
struct Beta: A, Hashable { //provide different hashing }
//now code that wants Beta uses its hashability,
//whilst code that expect A type, uses A's hashbility
//a bit simplified version of what I want, but correct
What do you mean by bags of syntax?
Depends on the case
Check this or this. It is true that semantic of the code might be covered from sight, but it can be mitigated with various assistance from IDE.
lorentey
(Karoy "Vector is not an Array type" Lorentey)
33
And why exactly would you ever want that? What specific problem requires you to have stable hash values?
Such a desire is fundamentally incompatible with the safety goals of the general-purpose hashing collection types in the Standard Library. I strongly recommend that you reconsider your requirements.
(Note: if you use a Hashable type that only implements hashValue in a Set or Dictionary, then the collection will still pass the returned integer through a Hasher to break up the overlong hash chains that are almost always produced by manual attempts at writing a hash function. Implementing hashValue is deprecated for good reasons.)
If you have a special use-case where you have full control over the input data you want to hash, then deterministic hashing may be a valid choice. In this case, the best way to go about it is to write your own custom hash table implementation. In most cases, this is considerably less difficult than implementing a good hash function.
You don't get to dictate what hash function the standard Set and Dictionary uses -- this is by deliberate design. However, in your own collection implementation, you are able to calculate hash values in whatever way you like!
No, this isn't a problem. If you must return a specific numerical value, simply define a separate property for that in your custom hashable-derived protocol, and in its default hash(into:) implementation, feed that value to the hasher. I can pretty much guarantee a hashValue-style protocol requirement will never be as convenient, reliable or efficient as simply implementing hash(into:) though.
I recommend you first concentrate on solving how to implement equality checks; the solution for hashing will follow directly from that. (The correct hash(into:) implementation can be (more or less) mechanically derived from the code for ==.)
(I don't see what this problem has to do with stable hash values, though.)
. They are boilerplate and does not compose well, for every combination of some traits, codebase would be bloated. I was baited by Protocol-oriented programming, sigh.