Deprecate UnrolledBuffer

[ashawley]

Somebody brought up scala.collection.mutable.UnrolledBuffer in the gitter channel. I guess there was some confusion about what it was for.

It appears that UnrolledBuffer is an internal-only class. It was marked sealed in 2.12 after it was deprecated for sub-classing in 2.11. Seems it is only needed for parallel collections, not for the collections generally. Someone should probably confirm that finding.

Parallel collections is going to be split out in 2.13. Maybe this class should be marked deprecated and moved to the new parallel collections module? It was probably just missed because it was brought over into the collection.mutable namespace in scala/scala@78a48c4. Is there a reason for it to stay?

PS. @SethTisue suggested a ticket be created to at least investigate if there was an oversight.

[joshlemer]

I think that an UnrolledBuffer may come well in handy sometimes, though I've never used it myself.

[Ichoran]

Being sealed and/or deprecated for subclassing is not in any way a sign that a collection is for internal use only. It means, instead, that the implementation relies upon the cooperative behavior of multiple methods and/or their interaction with internal data structures, and thus that subclassing attempts are likely to fail. That is: use the collection, but do not extend it.

That said, UnrolledBuffer is a weird beast and maybe should be deprecated. But that has nothing to do with the fixes to keep it from being brokenly-extended.

[NthPortal]

to add on to what @Ichoran said: List is sealed as well, and I don't think anyone is suggesting it ought to be deprecated and removed

[ashawley]

There is a companion object for UnrolledBuffer for constructing instances of UnrolledBuffer, so being marked sealed isn't a guard from being consumed by users.

[ashawley]

The discussion here is getting off the tracks. The motion under review is moving UnrolledBuffer to parallel collections. Going forward, hopefully the discussion can focus on that.

Admittedly, this is because I came up with a short title, "Deprecate UnrolledBuffer", but it probably should be "Move UnrolledBuffer to parallel collections". I presumed the former would be the resolution in the compiler code base to accomplish the latter.

I'm going to unsubscribe from the ticket. I reported it as a courtesy, but I don't have any knowledge to contribute further.

[Jasper-M]

It looks like it was once moved from parallel to mutable because it's not an internal or parallel-specific collection. Its private subclass DoublingUnrolledBuffer however seems to exist for the parallel collections.

[szeiger]

Let's revisit this once we have a clearer picture about what we need from it in parallel collections for 2.13. It's a usable collection type and it doesn't get in the way of anything so I'm in no hurry to remove it. We can still decide to deprecate it in 2.14.

[lrytz]

I'm looking at integrating scala-java8-compat into 2.13. It has Accumulator, which is very similar to UnrolledBuffer.

@Ichoran what are your thoughts on using UnrolledBuffer for the streams integration? It doesn't have the manual specializations though (IntAccumulator). If we port Accumulator, it seems to make sense to integrate it into the collections hierarchy.

[Ichoran]

@lrytz - Accumulator is outside the collections hierarchy and manually specialized precisely because this was necessary for it to be fast. You should benchmark again to see whether that has changed with the new collections. (Initializers were a source of slowdown.)

I think UnrolledBuffer would likely impose a major performance penalty, but I didn't test it specifically as far as I recall.

[szeiger]

Rescheduling to 2.14 for potential deprecation.

[SethTisue]

Let's revisit this once we have a clearer picture about what we need from it in parallel collections for 2.13

scala-parallel-collections does still use it in ParHashMap and ParHashSet. It can't switch over to using a locally in-sourced copy without breaking bincompat, which we're loathe to do since scala-parallel-collections is quite stable.