This is indeed a pretty simple extension. Could you please elaborate on whether you have an actual use-case for Class-based filtering or just would like to see the API aligned with Collection API?

Could you please elaborate on your use-case?

I would like it fixed for both real life use cases and consistency. I mostly implement protocols for communication applications (like XMPP). What ends up happening is that there are a lot of features that only listen to one type of message. So I usually end up writing a helper function to only get the message you want. It also ends up being more type safe, because I specify the inheritance of the generic parameter. If you just use filterIsInstance, you don't end up getting any type safety really due to the compiler just walking up the tree until it finds Any. Anyway if you just have the inline version, it becomes very hard to make a useful function without also exposing private variables.

    private val messages = MutableSharedFlow<Message>()

// with this new function I can do
    fun <T : Message> messages(clazz: Class<T>): Flow<T> = messages.filterIsInstance(clazz)
    inline fun <reified T : Message> messages(): Flow<T> = messages(T::class.java)

// without I have to expose a function I don't really want
    private fun messagesRaw(): Flow<Message> = messages
    inline fun <reified T : Message> messages(): Flow<T> = messagesRaw().filterIsInstance(clazz)

Implemented in #3464

Our workflow is different: a bot closes the issues automatically once the fixes are part of a release.

a bot closes the issues automatically once the fixes are part of a release

Some sort of wizardry! Sorry 😅

Yeah, it's kinda bummer from the maintenance perspective, but it is more transparent for users -- our master reflects the latest release, and open issues are one definitely not released yet

Hurray!