Nulls (was: Stream operations -- current set)

[Brian Goetz]

On 9/15/2012 10:24 AM, Doug Lea wrote:

> To further rub in how central the "little" issues of optional/null,
> (as well as numerics) are in all this, note that flatMap is just a
> special form of mapReduce(x->coll, addAll)

and filter() is just a special form of flatMap

> , which can be
> implemented so as to require a basis/default policy
> only if there is nothing there, so could do one of:
> (1) return null (2) accept an empty-collection generator as
> basis/defaultValue arg (3) return Optional (4) factor into
> a special flatMapper interface that absorbs the problem
> (as Brian chose; in CHM, I support unified forms of map+Reduce
> explicitly, which leverages intrinsic null policy to naturally use
> option #1, so method flatMap does not even appear.

We keep circling round the question of what to do about null values in 
streams.  Are they supported?  Banned?  Grumblingly tolerated?

As Doug points out, for concurrent collections, the sensible way to 
interpret null is "there's nothing there right now."  But, given that 
the streams API is built around an assumption of non-interference, we 
don't have to worry about "right now" as much; the contents of the 
stream source should remain constant during the course of the calculation.

If we'd bitten the bullet and not allowed nulls as elements in 
Collections from the beginning, we'd have less of a problem now.

So, looking at only the sequential case right now, what are the 
realistic options for handling nulls in streams?