Primitive streams and optional (original) (raw)

Tim Peierls tim at peierls.net
Wed Dec 5 07:22:58 PST 2012

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 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". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121205/cadd3a6d/attachment.html

More information about the lambda-libs-spec-experts mailing list