Tim Peierls tim at
Sat Sep 22 09:43:21 PDT 2012

On Sat, Sep 22, 2012 at 11:02 AM, Brian Goetz <brian.goetz at>wrote:

> 1. Stream operations ignore null elements.
> This interacts in an unfortunate way with a property I've been fighting to
> preserve -- size-preserving ops.  ...
> So I prefer to interpret your suggestion as "*may* ignore null elements".
>  So in this case, a reduction can ignore nulls, a find can ignore nulls,
> but "dense" ops can choose not to.

I'd hate to have to put null checks in mapping functions, though. How about
just "size-preserving in the absence of nulls"? I think of nulls as a case
to be allowed but not encouraged.

> This gets confusing for reduce, since currently we have:
>   T reduce(T base, Reducer<T>)    // trying not to upset Doug by
>   Optional<T> reduce(Reducer<T>)  // saying BinaryOperator<T>
> If we add a
>   T reduce(Reducer<T>, T defaultValueIfNone)
> the user will forever be confused between the first form and the third.

Can we really not find a way to pick just one of the first and third forms?
Yes, I realize there is a subtle difference between "base" and
"defaultValueIfNone", but I'm having trouble coming up with a realistic way
to be bitten by this.

(Shouldn't the default value come first, btw, to allow the remaining args
to end with a varargs?)


More information about the lambda-libs-spec-observers mailing list