Encounter order

[Brian Goetz]

> I think we're on the same page, but just to make sure my point is clear: choosing between Kind A and Kind B is fine; choosing both is also fine; what I would consider bad are:
> - Mixing Kind A and Kind B behavior into a single type (e.g., preserving order for 'map' but not 'into')

Each operation can have its own semantics, which includes what it does 
with encounter order.  For example, findFirst returns the first element 
of the stream in encounter order; findAny ignores encounter order 
completely, and is allowed to return a random element.  Both are OK and 
useful.

Similarly, I think we have latitude to define operations like into() 
either as producing a result or as having side-effects -- as long as we 
are clear which we are choosing.  Or having forEach and forEachInOrder. 
  But we should be clear that we are defining the semantics of the 
operation, not of the serial or parallel flavor of the operation.

>> For example, one question we could ask is "what happens when you
>> call reduce on a stream without an encounter order."  One
>> possibility is "hope that the reducer is commutative"; another is
>> to treat reduction on a order-less stream as an error.
>> Unfortunately we don't have ways in the type system to tag lambdas
>> as commutative or associative, so the user is on their own to avoid
>> GIGO here.  This isn't great, as it requires some nonmodular
>> reasoning on the part of the user.  On the other hand, this isn't
>> all that different from having to know "is this collection
>> thread-safe or not."
>
> So this is a Kind B stream.  I'm saying an error would never be what
> we'd want -- since this is a new type unrelated to Stream, if we
> don't want to support an operation, it simply doesn't exist.

I don't think so.  Stream sources are free to declare whether they have 
an encounter order or not.  We could of course decide all streams have 
an encounter order (imposed by their iterators).  But outlawing 
set.stream().reduce() seems pretty harsh.