Nulls

[Doug Lea]

On 09/22/12 13:39, Brian Goetz wrote:
> This is a pretty simple (maybe simpler) rule:
>   - Streams are completely null-oblivious (we don't treat them specially at all)
>   - Option is null-hostile.
>
> The Stream just passes values along, null or not, whether it be to user-supplied
> lambdas, the Option ctor, the add() method of a collection provided to into(),
> etc; if that recipient can't handle it, it blows up there.  If that recipient
> wants to ignore nulls, that's OK too -- it's outside of the Streams API spec.
> Then this mostly becomes a property of Optional.  (And, if we provide a
> default-bearing version too, if people want the null, they can use the other
> version.)

The main downside is that findAny is forced to lie (reporting absent)
if a null item matches predicate. Unless you want to reconsider
whether present Optionals can be null. Which no one seems to want to do.

-Doug



>
> On 9/22/2012 1:16 PM, Doug Lea wrote:
>> On 09/22/12 13:04, Brian Goetz wrote:
>>
>>> I would rather not punish everyone because some idiot puts nulls in a
>>> collection
>>
>> Unless that punishment is reduced to essentially nothing
>> (even (especially?) if it leads to even worse punishment for offenders).
>>
>> Remember that JVMs must do null checks all the time anyway.
>> Keeping track of whether you've even seen one, and thus must
>> throw away and/or repack a destination seems too cheap to
>> stand in the way of having a nicer rule.
>>
>> -Doug
>>
>