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

Joe Bowbeer joe.bowbeer at gmail.com
Wed Mar 6 11:31:35 PST 2013


I might be OK with Doug's suggestion. I want to see a complete proposal. I
think Remi's sugaring looks OK.

For Option lovers, one way to view this: it enables someone to provide
their own Option instead of the one we provide. Right? If not, then I'm
less favorable.
On Mar 6, 2013 10:56 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> > 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130306/c0f12f8f/attachment.html 


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