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

[Brian Goetz]

I've posted a survey for the EG at:

   https://www.surveymonkey.com/s/NSXMYC2

where people can express their preference between:
  - Leave things as they are (Optional-bearing methods for findXxx and 
reduce);
  - Add, as Doug suggests, non-optional versions of these too.

Implementation / spec complexity is a non-issue here -- the 
implementations are trivial.  The sole issue is whether the API is 
better with one version or with both.

The password has been communicated directly to the EG; contact me if you 
didn't get it.

Usual survey rules: enter your name with your response, all results will 
be made public after the survey closes.  I'll set a closing time of 6PM 
PT Wednesday of this week.


On 3/6/2013 7:09 AM, Doug Lea wrote:
> (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
>