Into (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed Dec 26 11:57:07 PST 2012

On 12/26/2012 08:11 PM, Brian Goetz wrote:

Since we can't read the user's mind about whether they care about encounter order or not (e.g., they may use a List because there's no Multiset implementation handy), I think we need to provide ways of aggregating that let the user explicitly choose between order-preserving aggregation and concurrent aggregation. I think having the word "concurrent" in the code somewhere isn't a bad clue.

This defeat one important purpose of the Stream API which is to be parallel/sequential agnostic from the user POV. Only to the extent that reality forces us to. The user has to declare whether they care about encounter order vs arrival order, or (equivalently) whether their reducers are associative or commutative. The user does have to understand this, otherwise we lose many of the benefits of parallelism by being forced to make bad assumptions.

you can hide that by asking what the user want as result.

Here having a toList() that take care about concurrency if needed is very appealing. Only if the cost of this is not that performance sucks in surprising ways. The performance of into() sucks in surprising ways.

into() sucks because it's currently implemented as sequential().into(). toList() doesn't require that and into() can be specified to avoid that.

Rémi

More information about the lambda-libs-spec-experts mailing list