What are you talking about? > It's premised on the idea that you can dynamically change the hash function such that eventually you will find one with fewer tha

What are you talking about? > It's premised on the idea that you can dynamically change the hash function such that eventually you will find one with fewer than some fixed number of items sharing the same hash value. Why would you think there are any fixed numbers? The OP is about a stdlib hash table (for Rust). Comparable hash table implementations all resize the table when necessary to decrease the load factor. Performance with respect to load factor still matters, of course, less resizing is better, but there are no fixed numbers of anything. > It completely undermines the "worst-case constant lookup", because there is no upper bound on the number of times you might have to change the hash function and rebuild the table before you find one with sufficiently few collisions. Why would you need to change the hash function or rebuild anything during lookup? It's lookup. Nobody is changing anything. > It is a much stronger requirement on the keys than other hash tables have. What hash table doesn't require keys to be hashable?