&gt; <https://developer.android.com/reference/kotlin/androidx/compose/runtime/Immutable> the doc of ...

# compose

[Peng Wang]

https://developer.android.com/reference/kotlin/androidx/compose/runtime/Immutable

the doc of @Immutable said that “data classes that only contain val properties that do not have custom getters can safely be marked as Immutable if the types of properties are either primitive types or also Immutable”
I thought the data class with val properties should have been treated as Stable (or Immutable) by Compiler , isn’t it ? if I don’t annotate Person with `@Immutable`，means the PersonView can’t skip the unnecessary Recomposition?

[Albert Chang]

If the types of val properties are all known to be stable, the compiler will infer the class as stable.

[Peng Wang]

so the @Immutable of Person in the sample doesn’t make any sense, right？ https://developer.android.com/reference/kotlin/androidx/compose/runtime/Immutable

[Paul Woitaschek]

Stable != Immutable. The compiler would infer it as stable but not as immutable

[Paul Woitaschek]

Also all this implies that you enabled compose for that module. So if you consume a class that is located in a module that does not have the compose plugin applied, the stability will not be inferred at all

[Peng Wang]

In terms of smart recomposition, what’s the difference between Immutable and Stable ?

[Albert Chang]

Actually Stable == Immutable.
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1626966996282200?thread_ts=1626898531.198700&amp;cid=CJLTWPH7S

[Albert Chang]

The compiler can infer the stability but it doesn't make manually marking classes pointless. You can see that all classes that are stable are manually marked in the framework. Marking a class ensures its stability and there are also some cases where the compiler can't infer the stability.

[Paul Woitaschek]

Oh that's interesting

[Paul Woitaschek]

I so wished I didn't need to mark everything containing a list or a platform class as stable

[Peng Wang]

I’m used to using data class to define my UiState, but I’ve never marked Immutable, and also I rarely see it in other people’s code. What I want to know is whether Immutable should always be marked for data class, even if it is stable. What is the bad case if don’t mark it for the data class? @Albert Chang

[Paul Woitaschek]

He already quoted that stable has the same effect as Immutable.
If it can't be inferred as stable it will cause recompositons

[Peng Wang]

the the Person of official sample, is stable itself right? why it still needs to be marked as Immutable ?

[Paul Woitaschek]

It's correct to mark it as Immutable but it's not necessary.
But if I understand correctly there is a distinction in the definition of immutable and stable that might be used one day by compose

[hfhbd]

Sooo, if you have another module containing only data classes in your project without compose, do you still need to mark them manually, (or apply the compose plugin)?

[Albert Chang]

You need to apply compose compiler plugin. Even if you mark them manually, if you don’t apply the compiler plugin, they will still be treated as unstable in other modules.