Nulls

[Brian Goetz]

Should stream ops be permitted to squeeze out nulls when they don't make 
sense?

For example:

   list...findFirst()

returns an Optional<T>.  There are good arguments why an Optional should 
*not* be allowed to contain null.  Should findFirst ignore nulls?  Throw 
something if the stream begins with null?

On 9/21/2012 12:04 PM, Joe Bowbeer wrote:
> My position is to support nulls in collections, which leads to
> supporting nulls in streams.
>
> I've never dealt with a popular language that didn't allow nulls --
> except for the concurrent flavor of collections in Java, which strikes
> me as implementation leaking through into design.
>
> That said, I don't like nulls, and when I'm using a language like Scala
> that allows me to eliminate them, I try to do that, and I feel bad when
> I can't.  But I still have nulls in some of my Scala code because it
> seems like the right thing in those cases.  Maybe if I were a better
> Scala programmer, then I would know of a way to eliminate them in those
> cases that would seem even better...
>
> Btw, I make a distinction with maps and their entries.  Maps don't
> contain null mappings, obviously, but I see some leeway regarding what
> objects are allowed in the map entries.  For example, I would not allow
> null keys, but would allow null values.  I think there's a similar
> distinction with streams.  That is, I would allow nulls in streams, but
> not null mappings (MapEntry) in MapStreams.
>
> Joe
>
> On Fri, Sep 21, 2012 at 8:37 AM, Kevin Bourrillion wrote:
>
>     On Fri, Sep 21, 2012 at 5:49 AM, Remi Forax wrote:
>
>         Support them is the only realistic option, there are too many
>         codes out there that put null in collections, otherwise it will
>         seriously impede the adoption of lambdas.
>
>
>     You would think so, but take a look at how hard Guava is on nulls,
>     and we pretty much get away with it.
>
>     There are always plenty of strategies for fixing your code to not
>     need to put nulls into collections, and most of them leave the code
>     better off.
>
>     I'm not taking a position on the issue, just saying the argument
>     that we /have/ to support nulls doesn't hold water with me. So
>     /what/ if it "impedes adoption" of lambdas a bit? Pleasing everyone
>     all of the time isn't an option anyway.
>
>