[feature request] add overloaded operators for nullable collection types

Libraries
1

So that I can

return listA + listB

if both lists can be null

instead of

return when {
  listA == null -> listB
  listB == null -> listA
  else -> listA + listB
}

Maybe also support + for non-nullable collection when the right hand operator is null, then return left operator.

1 Like
2

You can do return listA.orEmpty() + listB.orEmpty(), seems easy enough.

The problem I see with the suggestion is, that for a nullable collection, being null and being empty could mean very different things. Therefore, it might be better to be implicit with your intentions.

2 Likes
3

your code returns empty collection if both are null. Also it creates a bunch of empty collections.

Being null and being empty means different things, I agree, but how + operator for a nullable collection interferes with it?

If collection is null, return null, if it’s not do the same thing as with non-nullable collection.

4

could you provide a scenario where + operator for nullable collection gives wrong result?

5

the only issue i see if elements are nullable then it’s not clear what + should do, join collections or add a “null” element. Ok then maybe support “union” opearator instead, as it has works on 2 collections (and not individual elements).

6

E.g. having null + null == null, but null + empty == empty seems to be inconsistent to me: If null had some special meaning in this context, it is lost in the second expression. I think that nullable collections should be rarely used, and that you should avoid them when an empty collection does the job, especially because this kind of ambiguities.

Also, + is never used this way for other types, e.g. you can’t write 1 + null, and even for String?, where it is defined, you have null + null == "nullnull".

7

I agree with @Landei . If we have only a single empty case, then from my experience it is much easier to use non-nullable empty collections. Often, this pattern results naturally with exactly the behavior we need. For example, we iterate over a collection and for empty case we need to not iterate - with null we need to handle it explicitly, empty collection does this naturally.

If we have two separate empty cases then using null vs empty collection is enigmatic and we probably need another approach anyway.

It doesn’t. In both Java and Kotlin all empty collections created with utils like emptyList(), etc. re-use the same singleton object.

2 Likes
8

To you and also to @Landei

I’ve read “Kotlin in Action” second edition, although maybe not very thorough, and what I understood is that null is fine and ok in Kotlin, therefore null collection is also fine.

You say that null collection does not make sense or they don’t fit well. Where did you get that idea? Although I understand your point, iteration and other collection stuff does not work with null collections.

9

I don’t say null collections don’t make sense. You can use them and then do listA.orEmpty() + listB.orEmpty() as suggested above. Or even: (listA.orEmpty() + listB.orEmpty()).takeIf { it.isNotEmpty() } if you like to entirely avoid empty collections. I just shared my personal experience.

10

I would say null+null==null, empty+null==empty, empty+empty==empty. Return the value with the most data in it :smiley:

11

Generally, yes. What do you do if you need a number, but you don’t have one? You can use null, and because the Kotlin type system keeps track of it, it is totally fine. In that sense, null is is fine. Now, would you use something like Optional<Int>?? Well, it looks at least a little weird, Optional has a perfectly nice way to express that you don’t have a value. And I think similar about other collections. You can go even a step further, and use collections like NonEmptyList (from Arrow-Kt) to indicate that you always have at least one value.

The fact that Kotlin handles null way better than Java does is pretty cool, but it should be no excuse to use it just out of habit or laziness. In my personal code, you will find null values mainly on the “edges”, e.g. when dealing with the frontend or the database, especially when I have to use something like Spring. For the core functionality, I try to keep it null-free, or at least to resolve null as soon as possible.

12

I understand that I deviated from the original proposal. It becomes more clear to me that operators don’t make sense for null values, TY.

1 Like
13

I close my request.

14

Right, I didn’t know about that, thanks.
Plus operator creates a new one.

15

Ahh, this is a good point. Apparently, Kotlin doesn’t provide Collection + Collection operator, which could optimize for empty collections. Currently, it only provides Collection + Iterable.

16

As others have said, it depends what null means for a collection reference.

You could use it to mean an empty collection — but what would be the point? There’s already a better way to represent that (with an actual empty collection object), and so providing a second, inferior way to represent the same thing is pointless at best and often confusing/bug-prone.

Or, more likely, you could use it to mean something else — but there are many different, situaiton-specific things you could men, and then the way you want to combine lists will be specific to that, so no general solution is possible.

For example, I wrote a program in which a null set was taken to mean the universal set (‘all’), the opposite of the empty set (‘none’). It needed a few null checks, but it worked out pretty well and made good sense in context, and let me extend the intersection and union operators in a neat way. (But it wouldn’t make sense in other contexts, of course.)

1 Like