Loose ends: Optional

[Brian Goetz]

I got confirmation from the Fugue maintainers here.  They confirm that 
the null behavior of map() is as intended, and also that returning null 
from the flatMap function would be an outright bug, but they chose 
simply to not enforce it -- but also allowed as how they liked the idea 
of enforcing it.  So, I think what we've got is in the same spirit.

I don't follow your arguments about why flatMap "requires" fromNullable, 
but given that this is a feature that has also been widely requested, if 
that will bring this sad story to a close, then I'm good with it.

On 6/10/2013 3:14 PM, Brian Goetz wrote:
>> For flatMap, the rationale for "throw on null return" here is that:
>> Optional-returning methods should never return null (they should be
>> total functions, they can always return either a present or empty
>> optional), so a null return should be considered a programming error
>> (like trying to unbox the "null" Integer.)
>>
>> For map, it is different; it is entirely reasonable to imagine that the
>> mapper is a partial function, so, just like with computeIfAbsent, we
>> should interpret a null return as "no result".
>>
>
> Looking at the Fugue implementation, it differs slightly.  Their map()
> treats null-return as empty, and their flatMap simply returns null if
> the mapper returns null.  I am fine with being consistent with Fugue
> here; I think the lambda passed to flatMap should never return null, but
> we don't have to go out of our way to check it if we don't want.
>
> I've got a query into the Fugue guys to see if they're happy with that
> after having used it for a while.