Loose ends: Optional
Brian Goetz
brian.goetz at oracle.com
Mon Jun 10 12:14:07 PDT 2013
> 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.
More information about the lambda-libs-spec-experts
mailing list