Is `StateFlow<T>` mapping a planned feature? Right now I stick with Flow instead of StateFlow&...

# coroutines

[Orhan Tozan]

Is StateFlow<T> mapping a planned feature? Right now I stick with Flow instead of StateFlow<T> because it stops me from doing something like this:

// Example 1
val name: StateFlow<String> = ...
val greeting: StateFlow<String> = name.map { name ->
    "Hi, $name!"
}

// Example 2
val a: StateFlow<Int> = ...
val b: StateFlow<Int> = ...

val sum: StateFlow<Int> = combine(a, b) {a, b -> a + b }

[Jan Skrasek]

map{}.stateIn().
will be available in 1.4.0-M1, released very soon, probably today.

[Jan Skrasek]

Just released: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.4.0-M1

[Orhan Tozan]

I don't get why a CoroutineScope is required as a parameter

[Zach Klippenstein (he/him) [MOD]]

Because the upstream collection can outlive any one particular downstream collector. The passed scope defines the lifetime of that upstream collection.

[Orhan Tozan]

I'm sorry, I dont have really deep low level knowledge or coroutines, but doesn't your saying only apply to hot flows? I'm talking about a mapping a cold StateFlow, how is it different than mapping a regular Flow (where it doesnt need a CoroutineScope to define a mapping)

[Zach Klippenstein (he/him) [MOD]]

Sharing operators effectively turn cold streams into hot streams. Consider this example, with a fake shareInWithoutScope operator:

val upstream = flow {
  emit("starting")
  delay(1000)
  emit("finished")
}.shareInWithoutScope()

// First collector
launch { // this: scope1
  withTimeout(500) {
    upstream.collect {}
  }
}

// Second collector
launch {
  // this: scope2
  delay(250)
  upstream.collect {}
}

In order to collect upstream, the operator needs a scope to collect in. If this collection happens lazily, it could use the scope of the first collector (scope1). Then the second collector starts collecting in scope2 after 250 ms, which is fine. Then, at 500 ms, scope1 gets cancelled – but scope2 is still collecting, so the upstream collector needs to keep running. So sharing operators can’t rely on their downstream collector scopes to manage the shared collection.

[Zach Klippenstein (he/him) [MOD]]

As for why there’s no map operator on StateFlow that preserves the StateFlow type itself, see the discussion on this issue: https://github.com/Kotlin/kotlinx.coroutines/issues/2081

[Orhan Tozan]

Do you mean that stateIn() creates Hot flows? Why is that

[Zach Klippenstein (he/him) [MOD]]

Yes - a hot stream is one that it is "active" independently of downstream subscribers (whether there are zero, one, or 500). This is exactly what "sharing" or "multicasting" does, by definition. It creates a single upstream connection that is share between all downstream subscribers. This makes the resulting stream hot.

There are some gray areas: the resulting stream does act like a cold stream in that it will always emit a value to every subscriber on subscription, and if you're using reference counting, zero subscribers is treated differently than non-zero, but in general I think it's more accurate to say the returned flows are hot because they are relative to each downstream subscriber for most of their lifetimes.