Loose ends: Optional

[Brian Goetz]

Optional has obvious upsides and downsides.  Some of the downsides are:
  - It's a box.  Boxing can be heavy.
  - The more general-purpose value-wrapper classes you have, the more 
some people fear an explosion of unreadable types like 
Map<Optional<List<String>>, List<Optional<Map<String, 
List<Optional<String>>> in API signatures.

I think where we've tried to land is: do things that encourage people to 
use Optional only in return position.  These methods make it more useful 
in return position while not increasing the temptation to use it 
elsewhere any more than we already have.  Hence "mostly harmless".

On 5/24/2013 4:10 PM, Tim Peierls wrote:
> On Fri, May 24, 2013 at 3:20 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Proposed spec for methods on Optional, which would have the obvious
>     counterparts in Optional{Int,Long,Double}.
>
>     These methods are known to be useful and seem mostly harmless now
>     that other things have settled.  (I don't think they greatly
>     increase the moral hazard of Optional in general, and they do make
>     it more expressive.)
>
>
> I'm in the curious (unique?) position of both desperately wanting
> Optional and desperately *not* wanting lots of additional methods like
> these. If the price of having Optional is the presence of these methods,
> I'll suck it up, but "mostly harmless" is not exactly a ringing endorsement.
>
> --tim