Does <this> mean that (some) collections are now inferred as `@Stable`? :60fps_parrot: ```"kotlinx.c...

# compose

[Zoltan Demant]

Does this mean that (some) collections are now inferred as @Stable? 🦜

"kotlinx.collections.immutable.ImmutableList"
"kotlinx.collections.immutable.ImmutableSet"
"kotlinx.collections.immutable.ImmutableMap"

[Ben Trengrove [G]]

Yes, kotlinx immutable collections are now inferred as stable in 1.2.0-rc-01

[allan.conda]

Just curious listOf has been stable for a while, right? base on this
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]ability.kt;drc=e268b1151e73eac9c15aa17ce31dfefc8d749b70;l=235
I’m curious if we should replace everything with immutable list. We just found out today that one of the root cause of our performance issues are the unstable state classes (a Locale is not inferred as stable).

There’s also a recommendation before somewhere here in this Slack that we shouldn’t be worrying about manually adding @Stable and @Immutable normally, so I’m wondering if we should start doing so (since not worrying about it led to performance issue)

[allan.conda]

And I’m not sure the official docs talk about using @Stable and @Immutable yet to improve performance

[Ben Trengrove [G]]

If you have a composable that takes List<> as a parameter then that composable will never be skipped. Most of the time this won't matter but for composables that get recomposed a lot it starts to matter. I don't think I would go as far as replacing all lists in your app with immutable ones, but you could consider it for ones where you are measuring a performance penalty. Same goes with marking your model classes with Stable and Immutable, don't just do it blindly, do it when it has a measurable performance improvement