``` mainThreadScheduler.executeOnThread(Runnable {...

# codingconventions

[michaelsims]

mainThreadScheduler.executeOnThread(Runnable {
    result.errorResult.let {
        if (it == null) {
            taskCallback.onSuccess(result.successResult)
        } else {
            taskCallback.onFailure(it)
        }
    }
})

[alex.krupa]

How about something like this? (ignore the formatting, can't fit more lines in a sidebar thread)

mainThreadScheduler.executeOnThread(Runnable {
    result.errorResult
                ?.let { taskCallback.onFailure(it) }
                ?: taskCallback.onSuccess(result.successResult)
})

[geatmo]

I'm always a bit hesitant to use elvis with let, as let might return null, if its last expression is null.. so if taskCallback.onFailure(it) would return null for whatever reason, it would still call taskCallback.onSuccess(result.successResult) in this case

[geatmo]

I'd say go with the regular if here.. using let is unnecessary for this and I think a regular if is more idiomatic imho..

[Marc Knaup]

You could use ?.also instead of ?.let so it won't matter if the failure handler returns null.

[michaelsims]

Thanks Boris. I'd be interested in your opinions on what you would consider idiomatic use of let.

[geatmo]

hey Michael, sorry for the late reply!

[geatmo]

I don't know if I'm versed enough already with Kotlin to have a clear point on idiomatic uses of let, yet, but in general I feel that something like if (variable != null) { doThis() } else { doThat() } is for the most part better be left as a regular if else and using let would only end up being forced and confusing

[geatmo]

so regular cases, where I just want to execute something, if a variable is not null I do use let

[geatmo]

as a general rule of thumb for Kotlin, and the fancy code you can write with it, I would ask myself "do I need a comment for this, or is my intention with this line clear enough?", as one of the main points of Kotlin is readability

[michaelsims]

Thanks. No worries on the late reply, Slack threads suck. 🙂

[michaelsims]

I think my point is being lost here a bit because it's specifically about smart casting not being possible due to the use of a mutable or open property.

[geatmo]

ah, got you.. let me think about that

[michaelsims]

Ah, no worries. I think my question is a bit too abstract to be terribly useful. 🙂

[michaelsims]

Appreciate the feedback. 👍

[geatmo]

no, I think I actually ran into such situations.. I guess in that case it depends, but your use of let seems reasonable, although you could also just introduce a new val variable putting the value into.. as I said just depends on personal preference