Primitive streams and optional

[Tim Peierls]

Agree with Brian on all points below.

On Wed, Dec 5, 2012 at 10:02 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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".
>
>