You can also do this this to avoid the unsafe !! operator using the elvis operator and `let`: ``` f...

# getting-started

[karelpeeters]

You can also do this this to avoid the unsafe !! operator using the elvis operator and `let`:

fun main(args: Array<String>) {
    val map = mutableMapOf<String, Int>()
    val lst = mutableListOf<Int>()
    map["answer"] = 42

    for (arg in args) {
        map[arg]?.let { 
            lst.add(it)
        }
    }
}

[baermitumlaut]

I would, but I need an else in my specific use case.

[dalexander]

You could always use map[arg]?.let { ... } ?: <stuff to do when it's null> which may or may not look better to you.

[karelpeeters]

It surely is better then using !!.

[dalexander]

I would definitely use ?: on my own projects, I haven’t come to a conclusion about what I would decide for “projects with other people”.

[baermitumlaut]

Can you not do block statements after ?: ? This doesn't compile:

for (arg in args) {
    map[arg]?.let {
        lst.add(it)
    }?: {
        lst.add(0)
    }
}

[karelpeeters]

No, you need to actually call it. Try ?: run {...} or ?: {...}()

[karelpeeters]

I'd go for the former.

[dalexander]

run is better in my opinion. Or you could refactor your contingency plan into its own method and call that depending on what kind of local context you need.

[baermitumlaut]

I might do that, looks a bit convoluted now. Learned a lot though 👌

[Ruckus]

Personally I think the whole

someFun()?.let {
    ...
} ?: run {
    ...
}

is so much less clear than just

val someVal = someFun()
if (someVale != null) {
    ...
} else {
    ...
}

Sure it's technically a one liner, but Kotlin was designed to be clear, concise, and explicit, not cryptic 😛

[Ruckus]

(not to mention the potential downside of accidentally returning a null in the let block will also run the run block in the first example)

[karelpeeters]

Huh I didn't know that, learned something new today!

[Ruckus]

I made that mistake once when I accidentally left a nullable variable on the last line, not noticing it was the return value. I thought it was a bug in the std-lib for a while till I realized my (stupid) mistake. 😜

[dalexander]

If you don’t need the result couldn’t you use apply instead of let and avoid that trap?

[karelpeeters]

apply doesn't work, that uses the extension function thing. also works nicely though.

[karelpeeters]

Now I'm wondering why using let is an idiom at all...

[dalexander]

apply should work because it returns the receiver ie. null or not null, rather than the result of the closure you pass in.

[karelpeeters]

Right but apply isn't a drop-in replacement for let, the it-syntax doesn't work.

[karelpeeters]

Where also is one.

[dalexander]

Ah, you’re correct, you would have to use this in apply.

[Ruckus]

It's an insanely rare edge case. I still use ?.let { ... }, but usually only when it actually returns a value, not as a shortcut to if. Though it's just a personal preference.

[Ruckus]

@karelpeeters let has always been in the language, whereas also is relatively new, so it became the idiom.

[karelpeeters]

Right, that's the case where let is useful.

[karelpeeters]

I don't think I'll ever be able to remember all of those methods, do their names even have any meaning?

[Ruckus]

I'm not sure what you mean. The names seem reasonable to me.

[karelpeeters]

I don't know if it's just me but I can't really picture what a method called let would do. Same for also...