https://kotlinlang.org
Join Slack
`All deeply immutable types can safely be considered stable types.`What does this mean? A Kotlin dat...
# compose
m
`All deeply immutable types can safely be considered stable types.`What does this mean? A Kotlin data class with all 
val
is considered stable by the compiler then ?
c
If the variables reference objects which themselves only have vals, then yes it is safe to use 
@Stable
Copy code
@Stable // safe
data class A(
  val a: Set<String>
)

@Stable // Dangerous! Do not do this
data class B(
  val a: MutableSet<String>
)
etc
m
ok i see. thanks
wait. for example. 
data class A(val a: Int)
. does this need the annotation ?
h
Nope
c
Don't quote me on this, but I think the compiler is clever enough to know that your example is Stable—however it is correct to add the annotation in that case, if you want to be explicit.
a
m
I absolutely don’t like this. Having to declare classes as @Stable or @Immutable introduces a dependency on Compose into my model classes which I definitely want to avoid. Isn’t there any other way to achieve this effect? Maybe declaring stability at the point where the class is introduced into the Compose realm. What do you think?
👍 3
a
You don't have to declare them. The compiler plugin is able to infer them as long as you apply compose compiler plugin on the module containing the model classes.
m
But above you cited Adam Powel with a statement that says “Read-only collections such as List<T> are not [considered stable]” So can the compiler plugin figure out that I use the class in a safe manner? I doubt it. And what if they come from a library which does not know anything about Compose?
a
In that case you have to create wrappers in your current module if you really want to annotate them. After all the compiler plugin knows nothing about classes that are not in current module.
m
Would the compiler plugin automatically treat instances of https://github.com/Kotlin/kotlinx.collections.immutable as stable? Even if the come from a library?
a
c
Hopefully when we get value classes, the ‘stability’ of a type will be a language-wide feature, not a library annotation.
m
Or, in the meantime, provide a more general language-wide annotation for this aspect which is not bound to Compose.
d
+1 or at least decouple 
@Immutable
from 
compose.runtime
artifact and having them in something like 
compose.annotation
In that case you have to create wrappers in your current module
I wonder will wrapping in an annotated value class count? E.g.
Copy code
@Immutable
value class Wrapped(val value: MyTypeFromNonComposeModule)

data class ReadOnlyState(val value: Wrapped)
// ^^^ inferred as immutable?
a
d
thanks. I guess I was mainly concerned if maybe 
value
classes are treated differently, because... well.. they are removed in bytecode or at some stage of compilation where compose plugin may not see this annotation (speculating here)
a
They are not completely removed. And the compiler plugin processes IR, not byte code.
✍️ 1
66 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by