@tulio A few thoughts here: http://beust.com/weblog/2016/01/14/a-close-look-at-kotlins-let/ tldr: I tend to stick to

if

cedric:

let

is good for

var

, which must generally be avoided but it is needed sometimes.

Can you elaborate?

var

can change, and

let

extracts a local constant value (

it

). I just saw in the comments the one from ‘Justin Lee’, which gives the same reason

Ah yes indeed

if you want to avoid

it

and avoid renaming can’t you just shadow it?

thing?.let { thing -> thing.doStuff() }

Yes shadowing works too. Usually not recommended but it's basically the exact same variable, just transtyped from

T?

to

T

, so purists might give this infraction a pass

I do agree with what you are saying about if without else branch is typically a smell. it usually implies a stateful soupy mess imo

I don't connect the abence of

else

with statefulness (nor that statefulness is necessarily bad) but I do agree that the absence of a

let

is suspicious in my blog post

I tend to stick with

if

also. I find it much more readable in the long run when I go back to read the code.

Swift has a if let that allows for the else. Maybe in a new kotlin version

nullable?.let { doSomethingNotNull(it) } ?: doSomesingElse()

Is the construct for the else branch in Kotlin if i am not mistaken