A modern programming language that makes developers happier.

kotlinlang

are inline suspend parameters planned? e.g. when I want to execute some suspend lambda but want to wrap it in some `use` style code but don't want additional allocations.

Yes. See <https://youtrack.jetbrains.com/issue/KT-16603>

Also: <https://youtrack.jetbrains.com/issue/KT-16448>

<@U2E974ELT> actually, I was thinking of something slightly different:
```
inline fun launchWithDismiss(block: suspend () -&gt; Unit) = launch(handleExceptions = true) {
    try {
        block()
    } finally {
        dismissAllowingStateLoss()
    }
}
```
is this also covered by the issue?

That works now if you add “noinline” modifier before the `block` param. Should also work without “noinline” modifier if the issue I’ve quoted is fixed.

There's no difference in allocations between `inline` with `noinline` and leaving out `inline` altogether, right?

Btw, if all you want to do is to handle exception inside `launch`, then you don’t need it.

You need to define your own `CoroutineExceptionHandler`

See here: <https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental/-coroutine-exception-handler/>

I know, that's not what I want to do. What I want to do is dismiss a dialog, no matter how the coroutine terminates

ah I could do this with a context too, right?

You cannot do this with a context, but I think there is a better way to do it with coroutines:

```
val job = launch(context) { … doSomething ... }
launch(context + NonCancellable) { // !!! 
    job.await()
    dismissAllowingStateLoss()
}
```

In which way is this better? allocation-wise? Or elegance-wise?

but isn't my code pretty readable itself?

Actually, my version does _slightly different thing_, which may make it nonappropriate for your needs

Your code invokes `dismiss` when the original code completes (including whatever other cleanup there was), while my code invokes `dismiss` as soon as the job is cancelled (it may invoke `dismiss` before `doSomething` code had terminated)

pretty dangerous. what if activity/fragment has been destroyed before job is done?

<@U0BNGCVCK> this is a `DialogFragment` that has `retainInstance = true`

the whole job of the class is to run some code no matter what the activity lifecycle

it's a pretty neat idiom, if I dare say so. the user has some visual feedback that some work is being done and I don't have to take care of lifecycle issues