Anyone else uses something like this: ```fun <T> MutableCollection<T>.addNotNull(elem: ...

# stdlib

[Peter]

Anyone else uses something like this:

fun <T> MutableCollection<T>.addNotNull(elem: T?): Boolean {
    return if (elem !== null) add(elem) else false
}

I find it keeps my code more clean than all the if (elem !== null) { collection.add(elem) } boilerplate statements. I was always surprised it doesn’t come with stdlib already (or I couldn’t find it).

[Riccardo Lippolis]

I usually just do something like elem?.let { collection.add(it) } in that case. Probably the hassle of having to maintain this function if it's added to the stdlib outweighs the benefit of not having to define the function in case you want it 🙂 (as the implementation is pretty straightforward)

[wasyl]

I sometimes just add nulls and to filterNotNull() later, but I agree this case is surprisingly common for me

[Javier]

I think this is too short to add a shortcut for it

elem?.let(collection::add)

// vs

collection.addNotNull(elem)

[Rob Elliot]

collection.addNotNull(elem) is much easier to read though...

[Rob Elliot]

Spitballing but what about:

fun <X> X.addTo(xs: MutableList<X>) {
    xs.add(this)
}

elem?.addTo(collection)

Null handling is one of my favourite reasons for extension functions, but in this case it's a bit odd the way it reverses the natural order of elem and collection...

[wasyl]

It's both odd and pollutes the extensions space for all types 😕

[Peter]

Didn’t consider elem?.let(collection::add) Besides readability (although I guess depends how “functionally minded” you are) the difference is that the returned type is a Boolean? and not a Boolean. But anyway don’t require that feature.

[elect]

I'd rename `addIfNotNull`though