Maybe not related to coroutines but that s where I found it

Question

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 lt A gt ` 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 · Answer

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

octylFractal · Answer

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

octylFractal · Answer

and indeed that s what happens

okarm · Answer

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 lt A gt ` But it it has no problem setting `B` as value of `StateFlow lt A gt `

wasyl · Answer

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

octylFractal · Answer

it shouldn t have to don t make an unsafe cast

octylFractal · Answer

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

okarm · Answer

< 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 · Answer

And I just realized there s a difference between the two `public abstract class LiveData lt T gt ` vs `public interface StateFlow lt out T gt ` There s no out projection in LiveData

octylFractal · Answer

isn t that just because `LiveData` is a Java class not a Kotlin one

octylFractal · Answer

hmm I see what you mean now

octylFractal · Answer

I suspect it is due to that inconsistency with the type parameters `out T` allows such things as ```interface Source lt out T gt fun nextT T fun demo strs Source lt String gt val objects Source lt Any gt = strs This is OK since T is an out parameter ```

octylFractal · Answer

so kotlinc is able to infer `StateFlow lt Any gt ` from the `flow` and allow the unsafe set

octylFractal · Answer

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

araqnid · Answer

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