Documentation says - <https://developer.android.com/jetpack/compose/lifecycle#skipping> All primitiv...

# compose

[ritesh]

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>
}

[Adam Powell]

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.

[ritesh]

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

[Michael Paus]

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.

[Adam Powell]

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

[ritesh]

As, I was going through previous slack conversations
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1622473601442500?thread_ts=1622465932.419200&amp;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

[Arun Joseph]

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 ?

[Adam Powell]

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

[ritesh]

In what scenarios Immutable fits in or Stable fits in. As both annotations are marked with StableMarker adhering to the same contract

[Adam Powell]

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

[Adam Powell]

they're treated mechanically the same but carry different semantic meaning

[ritesh]

thanks adam