A hashability problem

#1 and #2 are orthogonal to #3, #4, and #5.

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:

public extension KitchenItem where Self: Hashable {
    func hash(into hasher: inout Hasher) { id.hash(into: &hasher) }
    static func ==(lhs: Self, rhs: Self) -> Bool { lhs.id == rhs.id }

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
mainStageTonight.max() //shoud compare them as MusicPerformer s

Don't you agree that this is a sound semantic?

So this is not acceptable?

let mainStageTonight: Set<ComparableMusicPerformer> = [

struct ComparableMusicPerformer: Hashable, Comparable {
  private var storage: MusicPerformer

  statuc func ==(lhs: Self, rhs: Self) -> Bool { ... }

Well, uhm, kinda, buuuut.... adapters, man! :sob:. 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.

To quote @jrose:

which should also apply equally as well here.

Ugh, that's obviously a poor man' solution, for an expression problem.

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.

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.)

1 Like