Round 2 feedback

[Brian Goetz]

>>> - groupingBy that returns a Map keyed by the Stream type is completely
>>> unintuitive. If not by the suggestion from the mailing list, I would never
>>> think of it as being applicable to my use case. A better name is certainly
>>> desirable;
>
> Sorry again, I meant joiningWith... I wrote this without having access
> to the actual code I've written...

So, the idea is you take a Stream<T> and a function T->U and you get a 
Map<T,U>.  If we had tuples, this would be stream.map(t -> (t, f(t))).

> Please correct me if I am wrong, but the toSet collector is not
> order-preserving for an ordered stream, right?

It is not order-preserving, but in a way the Stream library doesn't know 
about.

> That's why I think
> having collectUnordered as a different method feels odd.

Different sense of ordered/unordered.  More docs needed.  But 
collectUnordered is there for the cases that the library can't possibly 
figure out automatically.  Like you've provided an associative but not 
commutative combining function.  Or you just don't care about order. 
(The reason its even exposed is there are some significant optimizations 
that are possible if ordering is not a requirement.

> Some
> collectors are order-preserving, some are not and with some you can
> choose, but I think the choice should be made as you create the
> collector, not in the method call in Stream.

And that's a tiny sliver of the cases where ordering comes into play.

>> Is that sufficient?
>
> No, what I want is something like:
>
> numbers.optionalGet("six").orElse(0);
>
> You need something this concise to use maps in lambda expressions.

Can you post a more complete example?