inline operator fun <reified A : Screen> Store.invoke(f: context(A)(Action.() -> Unit) -> Unit): Unit =
    when (val screen = state.value.screen) {
        is A -> f(screen, ::dispatch)
        else -> Unit
    }

here a little helper function

Second of all, reified types obviously don't work when you don't know the type. For instance, if you're in a generic class, you can't use a type parameter as a reified type. This limits the extent of what you can do with those functions, and in fact in some cases it pushes developers to just use

Any?

As the reified type, which, in the case of that PR, would actually result in incorrect behaviour (I was very aware of that since I designed the code in that way and yet I fell for that and had to fix a resulting bug). Also, `Nothing`and

Nothing?

Can't be used as reified types, and so in the PR when I tried to create a

Some(null)

, I had to do

Some<Any?>(null)

A helper function like

Store.invoke

there is a perfectly valid use of

reified

. The issue with the PR is that the whole Option API would now be based on

reified

, with no intuitive reason as to why. The reason, if you're curious, is that I was using reified types to prevent boxing of nested Options by unravelling an

Option<Option<T>>

, and I'd only rebox the Option if the user was trying to access the value as an

Option

(thus relying on reified types to achieve that). It's a very hacky implementation, but it works. In your case, the reified type is clearly used for an

is

check, and the reification is limited to a few functions on the surface. Do note that this PR is suggesting a change to a pre-existing API, and thus it'll have to stand more to scrutiny vs if it were a new API