IssueTracker

We also want to achieve this result, but I don't think marking a parameter as @Stable was considered. I'll pass it along.

Also, maybe when determining whether a parameter is stable for recomposition, the compiler could look at the properties of the type actually being referenced in the function. So if a function takes the type

class MyData(
    val name: String,
    var indexInSomeTable: Int
)

and only references the name field, it should be considered stable.

Not sure about that last one.

I don't know how much the compiler plugin is able to infer/analyze, but although the name property is a val, it could be backed by a mutable property (or a function). This would not be stable in that case. But I really like the idea of adding the @Stable annotation to function paramters.

Would this also mean function parameters of a generic type would be able to be marked @Stable? That would be amazing.

Any updates on this? It seems like the least intrusive way to mark parameters of library types we don't own as @Stable or @Immutable, instead of having to create a wrapper for every single one of such types.

If #comment5 is also possible, then we can even solve the long-standing issue of Kotlin's List<T> being unstable in a pretty straightforward way, instead of having to replace all of them with Kotlinx's ImmutableList.

We don't believe marking function parameters is the right thing here, since it really is call-site dependent. I believe strong skipping mode should alleviate this pain significantly, so am now closing this bug.