Kotlin and idiomatic way to write, 'if not null, else...' based around mutable value

Question

Suppose we have this code:

class QuickExample {      fun function(argument: SomeOtherClass) {         if (argument.mutableProperty != null ) {             doSomething(argument.mutableProperty)         } else {             doOtherThing()         }     }      fun doSomething(argument: Object) {}      fun doOtherThing() {} }  class SomeOtherClass {     var mutableProperty: Object? = null } 

Unlike in Java, where you could be left alone to worry about null dereferencing at runtime, this doesn't compile - quite rightly. Of course, mutableProperty may no longer be null once within the 'if'.

My question is what's the best way to handle this?

A few options are apparent. Without using any new Kotlin language features, the simplest way is obviously to copy the value to a method-scope one that won't subsequently change.

There's this:

fun function(argument: SomeOtherClass) {     argument.mutableProperty?.let {         doSomething(it)         return     }     doOtherThing() } 

This has the obvious disadvantage that you need to return early or otherwise avoid executing the subsequent code - OK in certain, small contexts, but has a smell to it.

Then there's this possibility:

fun function(argument: SomeOtherClass) {     argument.mutableProperty.let {         when {             it != null -> {                 doSomething(it)             }             else -> {                 doOtherThing()             }         }     } } 

but whilst it has greater clarity of purpose, arguably it's more unwieldy and verbose than the Java-style way of dealing with this.

Am I missing anything, and is there a preferred idiom with which to achieve this?

Answer 1

Update:

As mentioned by franta on the comments, if the method doSomething() returns null, then the code on the right side of the elvis operator will be executed, which might not be the desired case for most. But at the same time, in this case, it is very likely that the doSomething() method will only do something and not return anything.

And an alternative: as protossor has mentioned on the comments, also can be used rather than let, because also returns this object instead of the result of the function block.

mutableProperty?.also { doSomething(it) } ?: doOtherThing() 

Original answer:

I would use let with Elvis operator.

mutableProperty?.let { doSomething(it) } ?: doOtherThing() 

From the doc:

If the expression to the left of ?: is not null, the elvis operator returns it, otherwise it returns the expression to the right. Note that the right-hand side expression is evaluated only if the left-hand side is null.

For a block of code after the right-hand side expression:

   mutableProperty?.let {             doSomething(it)         } ?: run {             doOtherThing()             doOtherThing()         } 

Answer 2

I don't believe there is a really "short" way to achieve it, however you can simply use a conditional within with or let:

with(mutableVar) { if (this != null) doSomething(this) else doOtherThing() } mutableVar.let { if (it != null) doSomething(it) else doOtherThing() } 

In fact, "capturing" a mutable value is one of the main use cases of let.

This is equivalent to your when statement.

There is always the option you described, assigning it to a variable:

val immutable = mutableVar  if (immutable != null) {     doSomething(immutable) } else {     doOtherThing() } 

which is always a nice fallback in case e.g. things get too verbose.

There probably isn't really a very nice way to achieve this because only the last lambda argument is allowed to be put outside the (), so specifying two wouldn't really fit the syntax of all of the other standard functions.

You could write one if you don't mind that (or if you'll be passing method references instead):

inline fun <T : Any, R> T?.ifNotNullOrElse(ifNotNullPath: (T) -> R, elsePath: () -> R)         = let { if(it == null) elsePath() else ifNotNullPath(it) }  ...  val a: Int? = null a.ifNotNullOrElse({ println("not null") }, { println("null") }) 

---

Note that I would personally not do this, because none of these custom constructs are very pleasant to read. IMO: stick with let/run and fall back to if-else when necessary.