Hmm, why is `Flow.firstOrNull` restricted to non nullable types? Feels like it'd be useful even with...

# coroutines

[ansman]

Hmm, why is Flow.firstOrNull restricted to non nullable types? Feels like it'd be useful even with flows with nullable types?

[Casey Brooks]

If it were used on a nullable flow, when that method returns you have no way of knowing if it was because the Flow emitted a null value, or if the flow closed without emitting anything. In the first case, null is a valid value, while in the second case, null is a signal of an error

[ansman]

Right, but that's up to the caller to decide if they want that or not

[ansman]

If you need that for nullable types just wrap it in an optional or something like that.

[louiscad]

Almost no one wraps values in optionals in Kotlin. You can use transformWhile for your use case.

[ansman]

For what use case? Getting the first element or null?

[louiscad]

firstOrNull for nullable types.

[ansman]

I still don't understand what you mean by that

[ansman]

The list version of firstOrNull() does not have this restriction and neither should Flow IMO

[ansman]

Just to be clear, I'm not asking how to implement this operator or an alternative. I'm asking specifically why firstOrNull does not allow nullable types when the list and array version does

[louiscad]

My two sentences were two distinct statements.

Here's a snippet to illustrate my second statement:

fun <E> Flow<E>.firstOrNullForNullables() = transformWhile {
    emit(it)
    false
}

[ansman]

Implementing this operator is trivial and that isn't what I'm asking for here

[louiscad]

You make a point with the List version. Might make sense to submit the API change request in GitHub issues then. Good news is that is should be binary compatible if it's accepted.

[ansman]

I opened an issue here: https://github.com/Kotlin/kotlinx.coroutines/issues/2229