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

[Brian Goetz]

I've closed the survey, results are at:

 
https://www.surveymonkey.com/sr.aspx?sm=c2NqWp6wXUxCUlr6SY05nYEyYIr7ShzH3IgL4OXPIYM_3d

Here, we did not reach a clear consensus.  However, I think some people 
may have misunderstood the question.  I'll let Doug, as proponent of 
this approach, take another swing at what is being proposed here, and 
why this might achieve best-of-both-worlds.

On 3/10/2013 7:22 PM, Brian Goetz wrote:
> 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
>>