brian.goetz at oracle.com
Fri Sep 21 09:08:18 PDT 2012
Should stream ops be permitted to squeeze out nulls when they don't make
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.
> 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.
More information about the lambda-libs-spec-observers