Into

[Brian Goetz]

>> 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.

> 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.