Got a class like ```@Immutable @JvmInline value cl...

# compose

[Stylianos Gakis]

Got a class like

@Immutable
@JvmInline
value class Foo(val values: Set<Int>)

And when generating compose metrics this gets read as unstable. When removing the @JvmInline and the value from it, and keeping the @Immutable (or @Stable) it does in fact get inferred as stable looking at the generated files. This must be a bug right?

[Zoltan Demant]

Using inline Foo in a composable function would be identical to specifying Set<Int>, which is unstable. It would be awesome if this somehow worked though, I made a post about it a while back - feel free to star it!

You can "work around it" by creating an interface, marked with @Immutable which under the hood is implemented by an inline class. Ive done this a ton and it works great, but theres a lot more code to write and maintain!

[Stylianos Gakis]

Right, I just found this issue too.
I understand how things compile down to a simple Set since it’s inline, but I was hoping since the class itself is marked as stable that it would work, just like it does if we make our own class to wrap the unstable thing and mark its stability ourselves.
But yeah, good to know that this is how it currently works at least, let’s see if this changes sometime in the future :D

[ste]

Last time I checked,

@Immutable
@JvmInline
value class Bar(val value: String)

was considered unstable too

[Stylianos Gakis]

Can confirm still in compose compiler version 1.3.1 and compose runtime 1.2.1
For fun

@Composable
fun Foo(bar: Bar) {
  Text(bar.toString())
}

Where Bar

@Immutable
@JvmInline
value class Bar(val value: String)

I get

restartable scheme("[androidx.compose.ui.UiComposable]") fun Foo(
  unstable bar: Bar
)

[Zoltan Demant]

Does it make any difference if you dont annotate the value class with @Immutable? Seems like a bug though.

[Stylianos Gakis]

Nope, still by removing @Immutable I get this

restartable scheme("[androidx.compose.ui.UiComposable]") fun Foo(
  unstable bar: Bar
)