Primitive streams and optional

[Brian Goetz]

>>>>>> 3.  Tolerate nulls.  This treat nulls as "just another value" and

I think there may be some confusion due to the way the word "tolerance" 
has morphed in recent years?  By "tolerate", we don't mean "all men hug 
and sing a song of unity", we mean "let's not have open violence in the 
streets."  Perhaps we should call this "barely tolerate."  As Doug said, 
the key casualty of this is modular reasoning about what will happen in 
various cases when there are nulls.  I view this as an acceptable cost, 
and one borne entirely by the null-lovers.  When we achieve a better 
world in which people don't put nulls in collections, it will become a 
purely theoretical concern.

>>>>>> hopes that
>>>>>> lambdas and downstream stages can deal.

The key is "hope".  We don't guarantee that all stages *can* deal, nor 
do we bend over backwards to accommodate.

For example, the semantics of findAny/First are (as currently written) 
pretty much incompatible with null-bearing streams.  The return type is 
Optional<T> where Optional can either represent the absence of value or 
a present non-null value.  So I think it is perfectly reasonble to say 
"if the stream contains nulls, this may throw NPE."

> As exemplified by the continuing set of patches for the
> continuing (and probably never-ending) list of cases noted
> on recent lambda-dev posts.

For many of these, I'm perfectly willing to specify that behavior in the 
presence of nulls is simply unpredictable; we're not necessarily 
patching things because we think they're bugs, so much as we're still at 
the point where patching is very cheap.

"Using null here may void your warranty".