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

[Brian Goetz]

> 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 already went around on this several times, made a decision, and no new information has come to light recently to warrant reopening the "do we want optional" discussion.  This is just raising the same arguments we've seen before.  Let's move on.  

On Mar 6, 2013, at 7:09 AM, Doug Lea wrote:

> 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.

This is a reasonable discussion to have.  Doug's list is not quite exhaustive -- there are also Option-bearing methods on the primitive streams such as min and max -- but its close.  

> So I'd like to re-propose a simple compromise.
> In the same way that there are Optional and
> basis-returning versions of reduce:

I am OK with adding these as they are dirt-simple and give people a reasonable path to an option-free lifestyle.  I am not OK with imposing an option-free lifestyle on everyone.  

> We have both proposed variants of this several times,
> but they don't seem to go anywhere.

Because they were only proposed as being *instead of* the Optional-bearing version, in which role they were deficient.  

> It would be nice
> to have a calm final discussion about why we would NOT
> do such an apparently sensible thing!

Agreed.  Willing to have a calm final discussion on these.