See: https://github.com/scala/scala/pull/8589#issuecomment-594216785
Maybe this isn't a real problem because the base classes HashMap and HashSet are sealed. So the only way to customise elemHashCode is to extend HashMap1, HashTrieMap etc.
They are marked as:
@deprecatedInheritance("This class will be made final in a future release.", "2.12.2")
class HashTrieMap[A, +B](
The choices are to add a defensive check that the operands of the optimized union are one of the known subclasses, or to agree this isn't a supported extension point.
Also the pre-existing implementations of HashMaps union/diff/intersect/merge/filter/++/-- …. and any other methods that traverse the tree of HashMap objects that assume the tree structure and bit representation of the hashcode is consistent between the receiver and the parameter
The same problem for HashSet, but fewer methods
the optimisations for the builders (in https://github.com/scala/scala/pull/8722 and https://github.com/scala/scala/pull/8726) may need consideration for the ++ optimisations
I'm leaning towards release noting the known breakage because I believe its more a theoretical problem than something that exists in the wild.
HashTrieSet is missing the deprecatedInheritance, but still, I agree this is extremely unlikely to break anything.
it would also affect HashSet/HashMap equals and HashSet subsetOf
I agree that it seems more a theoretical issue than a practical one
This also was an existing issue in 2.12 HashMap union/diff/intersect/merge as they were already tree based. The difference is that its now exposed via ++ -- filter etc
for merge this issue dates back to 2.9! https://github.com/scala/scala/blob/2.9.x/src/library/scala/collection/immutable/HashMap.scala#L392
Most helpful comment
I'm leaning towards release noting the known breakage because I believe its more a theoretical problem than something that exists in the wild.