Until 2.12 it was possible to access m.HashSet's internal table. This is useful, for instance, to pick a pseudo-random element of the set in a O(1) manner. One way to access the internal table was to call private[collection] def hashTableContents.
In 2.13 this seems no more possible, right? If so, could you please re-add this functionality?
That’s a private API; using it was always unsupported and it technically can be removed even in a 2.12 release.
For a random element I’d use table(Random.nextInt(table.size)).
You cannot access table, and you shouldn’t. It is and has always been a private API.
If you were willing to break language protections using your own class inside package scala.collection, then maybe you’re also willing to use runtime reflection to break the protections.
@sjrd I certainly understand the risk and your NO based on this risk. But then, what is the current policy regarding collection implementation extendability?
I remember that about 3 years ago the core team discussed and decided on scala-internals that it made no sense to extend immutable collection implementations but could make sense to extend mutable ones. Is this policy broken intentionally?
Extensibility has little to do with private implementation details. In some cases, it’s possible to provide protected hooks for extensibility, when they can be clearly specified. But the internal mutable table of a HashSet is typically too much, unless one is willing to commit the particular hashing, structuring, bucket sizing, etc. all in the specification of the class. And that’s usually not a good thing to do, because it prevents improving these things in later versions.