Encounter order

[Brian Goetz]

Maybe...

If you accept that set.findFirst is not a syntax error (not yet agreed, 
but I'm pushing this story), then list.unordered.findFirst shouldn't be 
either.  What .unordered would mean is "I know there's an encounter 
order, but I don't care about it, do things as fast as you can."

In reality this wouldn't likely affect the performance of reduce, 
findFirst, etc.  But it would likely improve the performance of groupBy, 
uniqueElements, etc.

On 10/25/2012 7:14 PM, Dan Smith wrote:
> On Oct 25, 2012, at 10:00 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>>   list.unordered().uniqueElements().toArray();
>
>> Given this, my recommendation is:
>> - Provide an .unordered() op for people to opt out of the encounter order when they know they don't care.
>
> Ah, 'unordered' is my 'asKindBParallel' operation.  To make my previous discussion concrete, I'm arguing that the result of 'unordered' -- call it an 'UnorderedStream' -- should _not_ extend 'Stream', but rather should have its own set of operations that make sense in an unordered world (e.g., no 'findFirst', no 'skip', commutative-op-only 'reduce', etc.).
>
> (Back to my cave now...)
>
> —Dan
>