dl at cs.oswego.edu
Sun Sep 23 05:07:10 PDT 2012
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
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.
> 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
>> 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.
More information about the lambda-libs-spec-observers