Maybe not related to coroutines, but that's where I found it: Can anybody explain to me why the foll...

# coroutines

[okarm]

Maybe not related to coroutines, but that's where I found it:
Can anybody explain to me why the following code works? https://pl.kotl.in/O8wu8VKSE

In essence the code sets an instance of type B as a value of StateFlow<A>. I would not expect that to be possible. The code not only compiles, it actually runs in the Playground without a run-time exception.

[octylFractal]

because you forced an unsafe cast and you're never type checking, so the generic doesn't come into play (generic type erasure)

[octylFractal]

if you did val a = flow.value I would expect an exception as kotlin should introduce a cast there

[octylFractal]

and indeed, that's what happens

[okarm]

Well, when the very same implementation is used with a LiveData receiver (casting LiveData to MutableLiveData as opposed to casting StateFlow to MutableStateFlow), compiler doesn't allow posting B to LiveData<A>. But it it has no problem setting B as value of StateFlow<A>

[wasyl]

I suppose it is a bit surprising that MutableStateFlow doesn’t perform any checks when setting value of a wrong type 🤔

[octylFractal]

it shouldn't have to, don't make an unsafe cast!

[octylFractal]

additionally, it can't -- it has no type information, that's how erasure works

[okarm]

@octylFractal If it can't then how is it possible that with LiveData it correctly infers an attempt to set a value of incompatible type, refusing to even compile? I have no problem with the behavior, but I dn't know why it's inconsistent.

[okarm]

And I just realized there's a difference between the two.
public abstract class LiveData<T> vs public interface StateFlow<out T> - There's no out-projection in LiveData

[octylFractal]

isn't that just because LiveData is a Java class, not a Kotlin one?

[octylFractal]

hmm, I see what you mean now

[octylFractal]

I suspect it is due to that inconsistency with the type parameters -- out T allows such things as:

interface Source<out T> {
    fun nextT(): T
}

fun demo(strs: Source<String>) {
    val objects: Source<Any> = strs // This is OK, since T is an out-parameter
    // ...
}

[octylFractal]

so kotlinc is able to infer StateFlow<Any> from the flow and allow the unsafe set

[octylFractal]

this is why MutableStateFlow doesn't declare out T, but just T -- since it prevents input from being promoted to Any

[araqnid]

That’s why MutableList etc are invariate compared to List in general