(1) ```fun load() = scope.launch { ... }.ignore()``` where `.ignore()` returns `Unit` vs. (2) ``...

# random

[darkmoon_uk]

(1)

fun load() = scope.launch {
    ...
}.ignore()

where .ignore() returns Unit vs.
(2)

fun load() {
    scope.launch {
        ...
    }
}

Vote 1️⃣ or 2️⃣

[ephemient]

2️⃣, but also: .let {} is built-in .ignore()

[ephemient]

if you really wanted to put it on one line but with "readable" extensions, you could

infix fun <T, U> T.withSideEffect(ignored: U): T = this

fun load() = Unit withSideEffect scope.launch {
    ...
}

but I think that's total overkill

[Mustafa Ozhan]

I have this actually

fun CoroutineScope.launchIgnored(function: suspend () -> Unit) {
    launch {
        function()
    }
}

then i use as

fun load() = scope.launchIgnored {
    ...
}

[Sam]

I’m curious, how often do you encounter scenarios where you need load to return Unit instead of a Job? In most places I can think of, it doesn’t matter. I would just return a Job and ignore it at the call-site. The main exception I can think of is if it’s an override and you don’t control the return type.

[Mustafa Ozhan]

it is really needed if you have an interface method that needs to return Unit but because launch returns Jobs it gives errors

[darkmoon_uk]

@Sam Where this is a public library function and we don't want to give the consuming application the opportunity to cancel the Job (or otherwise interfere with internal handles)

[mcpiroman]

Could also be

fun load(): Unit = scope.launch {
    ...
}

[Sam]

☝️ sadly that doesn’t work (at least not for me) 😞 implicit Unit conversion is only possible for lambda functions right now.

[Sam]

I think it’d be nice if that did work, though.

[ribesg]

If your problem is just with the additional indentation, there's no issue doing something like this

fun load() {
    scope.launch {
        task()
    }
}

suspend fun task() {
    …
}

You could even have some error management in load() instead of in task() so that task() is easier to read