Why do the author need to add <Async<List<Task>>> for catch in Flow in Kotlin?

The following code comes from the project.

And _filteredTasksAsync will return Flow<Async<List<Task>>> .

I don't know why the author need to add <Async<List<Task>>> for catch in Flow in Kotlin?

You know the the .map{} needn't to add .map<Async<List<Task>>> {}

private val _savedFilterType =
        savedStateHandle.getStateFlow(TASKS_FILTER_SAVED_STATE_KEY, ALL_TASKS)

    private val _filterUiInfo = _savedFilterType.map { getFilterUiInfo(it) }.distinctUntilChanged()
    private val _userMessage: MutableStateFlow<Int?> = MutableStateFlow(null)
    private val _isLoading = MutableStateFlow(false)
    private val _filteredTasksAsync =
        combine(taskRepository.getTasksStream(), _savedFilterType) { tasks, type ->
            filterTasks(tasks, type)
        }
            .map { Async.Success(it) }   // .map <Async<List<Task>>> { Async.Success(it) }  isn't necessary
            .catch<Async<List<Task>>> { emit(Async.Error(R.string.loading_tasks_error)) }   //.catch { emit(Async.Error(R.string.loading_tasks_error)) }  will cause error


sealed class Async<out T> {
    object Loading : Async<Nothing>()    
    data class Error(val errorMessage: Int) : Async<Nothing>()    
    data class Success<out T>(val data: T) : Async<T>()
}

catch on Flow is defined as: (https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/catch.html)

fun <T> Flow<T>.catch(action: suspend FlowCollector<T>.(cause: Throwable) -> Unit): Flow<T>

Therefore, if you specify <T> in catch, that would only be required if it could not be inferred, which cannot be determined solely from the context of the given code, but I am assuming that since the type of Action in map could be inferred, the explicit <T> is not required, however it would make the type of the Flow<Async.Success<List<Action>>>, which is not equal to Flow<Async<List<Action>>>, so the sole purpose here is to "downcast" the flow explicitely.

When you omit <…>, you are allowing the generic type of the function to be inferred. With map, you can always omit it, because the type can be inferred to be whatever type you are returning from the lambda.

With the catch call here, it would be able to infer the type if you were emitting the same type as the known type of the flow returned from the preceding map operator. However, the returned type of the Flow from the map operator is Async.Success. In the catch operator, we are not emitting Async.Success so the types don’t match and therefore cannot be inferred. We need to specify the nearest common parent type which is just Async.

You could also move the generic type specification up to the map line, and then it wouldn’t be needed for the catch line:

.map<Async<List<Task>>> { Async.Success(it) }
.catch { emit(Async.Error(R.string.loading_tasks_error)) }

IIRC, they have recently improved the Kotlin compiler so you don’t have to specify every detail of a nested generic type if it’s not changing, so I think this would work:

.map<Async<_>> { Async.Success(it) }
.catch { emit(Async.Error(R.string.loading_tasks_error)) }