Add `asFlow()` extension for `SharedFlow`

[g000sha256]

Currently, kotlinx.coroutines provides:

fun <T> MutableSharedFlow<T>.asSharedFlow(): SharedFlow<T>

and

fun <T> MutableStateFlow<T>.asStateFlow(): StateFlow<T>

to hide mutability.

However, there's no convenient way to hide the "hot flow" nature and return a simple Flow<T> that cannot be cast back to the original type. I suggest to add:

fun <T> SharedFlow<T>.asFlow(): Flow<T>

This would provide a clean, zero-overhead way to expose hot flows as a plain Flow interface.

Use cases

• API design where implementation details (SharedFlow/StateFlow) should not leak.
• Preventing clients from accessing replayCache, subscriptionCount, or value.
• Consistent return types in interfaces that may use different Flow implementations.

private val _mutableSharedFlow = MutableSharedFlow<Value>()
override val values: Flow<Value> = _mutableSharedFlow.asFlow()

[Komdosh]

What's wrong with:

val values: Flow<Value> = _mutableSharedFlow.asSharedFlow()

[g000sha256]

@Komdosh, yes, SharedFlow is already a Flow, but a simple assignment allows casting back to the original type:

class Repository {
    private val _mutableSharedFlow = MutableSharedFlow<Value>()
    val values: Flow<Value> = _mutableSharedFlow.asSharedFlow()
}

// Client code can break encapsulation:
val sharedFlow = repository.values as SharedFlow<Value> // Success!
// Now the client can access replayCache, subscriptionCount, etc..

The proposed asFlow() would return a wrapper that prevents such casting, similar to how asSharedFlow() prevents casting back to MutableSharedFlow:

val values: Flow<Value> = _mutableSharedFlow.asFlow()

// Client code:
val sharedFlow = repository.values as SharedFlow<Value> // ClassCastException!

This is about enforcing encapsulation at runtime, not just at compile time. It ensures that implementation details (using SharedFlow internally) don't leak to consumers who should only depend on the Flow interface.

[Komdosh]

So this is an error too?

public fun main(){
    val l: List<String> = mutableListOf("0", "1").toList()
    (l as MutableList<String>).removeAt(0)
    println(l) // ["1"]
}

[g000sha256]

@Komdosh, actually, looking at the implementation of asSharedFlow():

/**
 * Represents this mutable shared flow as a read-only shared flow.
 */
public fun <T> MutableSharedFlow<T>.asSharedFlow(): SharedFlow<T> =
    ReadonlySharedFlow(this, null)

It creates a wrapper that explicitly downgrades the interface from MutableSharedFlow to SharedFlow and prevents casting back to MutableSharedFlow. This is exactly the pattern I'm proposing for asFlow(). This would make the API consistent within kotlinx.coroutines itself. The library already chose to protect against casts with wrappers, so why not complete this pattern?

The comparison with stdlib's toList() doesn't seem applicable here, because kotlinx.coroutines already uses wrapper-based protection. But, in my opinion, it would be better if toList() worked similarly.

[dkhalanskyjb]

This function makes sense, yes. We can't make asFlow() zero-overhead (there will still need to be a wrapper), but there should be close to no overhead.

As a workaround, .map { it } can be used:

fun <T> SharedFlow<T>.asFlow(): Flow<T> = map { it }

@g000sha256 , would you like to contribute the implementation?

@Komdosh,

So this is an error too?

My personal opinion is that yes, it's an error. If an author of some component relies on their List<T> being unchanged, but then some client code modifies the list anyway, that's just asking for trouble. Unfortunately, .toList() and listOf() are such fundamental functions that I don't think we can fix them without breaking real code.

[Komdosh]

With the 'List' example, I wanted to show that there are many potential mistakes. As clients, we should not access and reveal the internal implementation. We can do it anyway using reflection, for example. This doesn't actually break the code's logic. If a client wants to break it, they can. An interface is a usage contract that is supposed to be used as intended. If a client wants to break the rules, they will.

If we tried to restrict such behavior by assuming the client will never follow the interface, the code would become heavily over-engineered. Therefore, I think it's a necessary compromise: if you choose not to follow the interface, the consequences are your own responsibility.

[dkhalanskyjb]

The problem is when the cast happens unintentionally. If you use reflection and access the internals of some data structure, you probably know that you're breaking the contract with the library author. Casts can be performed without realizing it, or the effects may be subtle.

Here's an artificial example that hopefully illustrates the point:

// copy-on-write when we mutate the list, initially immutable
var myUsers: List<User> = UserRepository.getCurrentUsers()

fun addUser(newUser: User) {
    if (myUsers is MutableList<*>) {
        (myUsers as MutableList<T>).add(newUser)
    } else {
        myUsers = myUsers.toMutableList()
        addUser(newUser)
    }
}

Nothing in this code screams "addUser modifies the object provided by UserRepository" to me, and this code will work perfectly well if getCurrentUsers is implemented like this:

fun UserRepository.getCurrentUsers() =
    queryDatabase("users").map { it.parseUser() }.toList()

The myUsers is MutableList<*> check is pointless, but also harmless, as every getCurrentUsers() call will have its own copy of the list of users.

The code will stop working well if getCurrentUsers is changed to

fun UserRepository.getCurrentUsers() = if (nothingChanged) {
    usersCache
} else {
    usersCache = queryDatabase("users").map { it.parseUser() }.toList()
    return usersCache
}

Now, addUser performed in the local copy will affect every other consumer of getCurrentUsers().

I haven't heard of this actually happening because of .toList()/listOf(), so it's probably not a big deal. Still, it's not impossible that such code gets accidentally written, so I still consider this a Kotlin stdlib bug (one that we probably can't do anything about at this point, unfortunately). As library authors, we shouldn't gamble on well-meaning, contract-abiding users not writing some specific code that may behave incorrectly.

[g000sha256]

@dkhalanskyjb, I've created #4541