RFR : JDK-8001642 : Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong

[Doug Lea]

(Restricting to lambda-libs list...)

On 03/06/13 04:47, Remi Forax wrote:
> Ok, let be nuclear on this,
> There is no good reason to introduce Optional<T> in java.util.

We agree about most of the rationale for not using Optional.
But there are still people who say they want it.
I don't think it is productive at this point to
argue about features supporting an Optional-laden
programming style. But we never seem to hit closure
about features supporting an Optional-free style.
So I'd like to re-propose a simple compromise.
In the same way that there are Optional and
basis-returning versions of reduce:

  T reduce(T identity, BinaryOperator<T> reducer);
  Optional<T> reduce(BinaryOperator<T> reducer);

(Where the basis-returning one can in turn be used to
avoid Optional-returning min(), etc). We should do the
same at least for find, or  more in keeping with current
API, findFirst and findAny:

  T findFirst(Predicate<? super T> predicate, T ifNone);
  T findAny(Predicate<? super T> predicate, T ifNone);

People wanting to avoid Optional can then then
get all of the derived versions (allMatch, plain
findAny, etc) easily enough.

Surprisingly enough, that's the only missing
feature that would otherwise enable a completely
Optional-free usage style of the Stream API.

We have both proposed variants of this several times,
but they don't seem to go anywhere. It would be nice
to have a calm final discussion about why we would NOT
do such an apparently sensible thing!

-Doug