HashSet (and maybe Map?) optimizations backported to 2.12.x don't respect possiblity of custom elemHashCode

[retronym]

See: scala/scala#8589 (comment)

[retronym]

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](

[retronym]

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.

[mkeskells]

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

[mkeskells]

the optimisations for the builders (in scala/scala#8722 and scala/scala#8726) may need consideration for the ++ optimisations

[retronym]

I'm leaning towards release noting the known breakage because I believe its more a theoretical problem than something that exists in the wild.

[lrytz]

HashTrieSet is missing the deprecatedInheritance, but still, I agree this is extremely unlikely to break anything.

[mkeskells]

it would also affect HashSet/HashMap equals and HashSet subsetOf

I agree that it seems more a theoretical issue than a practical one

[mkeskells]

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