Forms for reduce() -- part 1

[Brian Goetz]

>> Open question: do we keep the name mutableReduce to make it clear what
>> is going on?
>
> If you went without the name, I'm not sure how clear it will be with the existing types that one is mutating or non mutating.  Would this make sense, or not so much?
>
>        <U> U reduce(U zero,
>                     BiFunction<U, T, U> nonMutatingAccumulator,
>                     BinaryOperator<U> nonMutatingReducer);
>
>        <R> R reduce(Supplier<R> seedFactory,
>                     BiBlock<R, T> mutatingAccumulator,
>                     BiBlock<R, R> mutatingReducer);

There's no reason this doesn't *work*.  My concern was that calls of 
both will involve lambdas of two arguments, and it will be less obvious 
by reading the code whether (a, b) -> goo is being used as a functional 
reducer or a mutable accumulator.  The parameter names will not be 
present at the use site, so readers of the code will have to reason 
about whether this is a functional reduce or a mutable inject.

So, the question remains -- is the word "mutable" (or some other way of 
saying that) a helpful guide about what is being done here, or pedantic 
noise that will irritate the users?  (Note that I think we should care 
much less how it makes people feel when *writing* code than how it helps 
comprehension when *reading* code.)

> These are APIs we've had in a separate library for several years that we've moved into GS Collections RichIterable interface and which will become available in our 3.0 release.  They are a combination of groupBy/injectInto so certainly have some differences to reduce, but they also have some similarities in terms of supporting mutating/non-mutating versions.  We chose not to go with the name mutableAggregateBy, but instead named the parameter mutatingAggregator or nonMutatingAggregator.  We felt the difference in type made it pretty clear (Function2 vs. Procedure2).

The type does make it clear when the call site has "new Function() { ... 
}".  Which of course described many call sites in a pre-lambda world. 
In a post-lambda world, the type is inferred, and both functions and 
blocks often look similar at the use site:

   (a, b) -> a+b
   (a, b) -> a.add(b)  // where add(b) is void-bearing and mutative