Documentation says - https://developer.android.com/jetpack/compose/lifecycle#skipping All primitive value types, strings and lambdas are

Stable

- as they are declared immutable. When declaring a data class or a class which can hold an immutable read-only list, should we mark it as

Immutable

as data-structures are not Stable by default? Or compose compiler can infer?

@Immutable
data class MyClass {
 val someId:Int,
 val myList:List<SomeClass>
}

If you're going to do the above and you promise you will only ever use immutable lists with it, then yes you can annotate the class as immutable. The compiler plugin won't infer it since

List

is read-only, not immutable.

Does it makes a difference in this case, in terms of performance/recomposition, if do-not mark the class as

Immutable

as list isn't (it's read-only), but at my end the

List

reference is always going to be same but the value it's holding can be a different instance over the time or modify few of its properties, that can/should end-up re-composing only that row/column if it's inside a

LazyColumn

or

LazyRow

I’d like to keep my models clean from any dependencies on any GUI framework including Compose. Are there any alternative ways to tell Compose that a model class is stable/immutable? What about https://github.com/Kotlin/kotlinx.collections.immutable ? Does Compose treat these classes a stable/immutable by now? Technically I could imagine that this could also be done on the usage side. E.g., when you use

.collectAsState()

there could be a parameter where I could tell Compose that the state in question can be treated as stable/immutable. The

@Stable

annotation is also just a promise which is technically neither validated nor enforced.

There's a feature request filed on the tracker somewhere to have a way of sideloading lists of types to treat as stable, I don't have it handy at the moment

As, I was going through previous slack conversations https://kotlinlang.slack.com/archives/CJLTWPH7S/p1622473601442500?thread_ts=1622465932.419200&cid=CJLTWPH7S I believe this is something which is probably needed IMO. If my data class holds multiple data-structures, i do-not want to create a wrapper for each and mark them as @Immutable

I use

StateFlow

for ui state and use

state.copy(property = something).emit()

for state updates. So I think this might cause problems. Is there any trick to wrap

collectAsState

to tell that it is

@Immutable

?

Stability is a property of the type, not of return values from specific functions

In what scenarios Immutable fits in or Stable fits in. As both annotations are marked with

StableMarker

adhering to the same contract

please don't @-mention for thread replies like this. I'll see it.

thanks adam