How can a function with unstable values be restartable & skippable? All documentation Ive read o...

# compose

[Zoltan Demant]

How can a function with unstable values be restartable & skippable? All documentation Ive read on the subject tells me that this is impossible, or is it?

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun BottomBar(
  unstable pages: List<ExplorePage>
  stable currentPage: ExplorePage
)

[izanrodrigo]

Maybe you could use Kotlin’s Immutable Collections to make the parameter stable. https://github.com/Kotlin/kotlinx.collections.immutable

Check this out for more info: https://medium.com/androiddevelopers/jetpack-compose-stability-explained-79c10db270c8

My bad, I misread the post 😬

[Stylianos Gakis]

The concern isn’t about how to make it stable, but how could the function be inferred as skippable while the parameter passed into it is in fact unstable.
Super curious about this one too, I don’t quite get it either.

[Zoltan Demant]

I just had to verify that its actually being skipped, and it is mind blown

[Csaba Szugyiczki]

Are you actually “using” the pages parameter, or just pass it down to another Composable?

[Zoltan Demant]

Yup, Im using it in the same composable!

[mcpiroman]

AFAIK compose uses even more magic, to track down some possibly stable parameters at runtime (via bitmasks). So that if you a parameter of List<>, it is unstable at compile time, but when you directly pass an argument of listOf(), it knows that the returned list is immutable and may consider that single invocation of a function as skippable.

[mcpiroman]

Though that feature is likely very limited ATM and only supports some stdlib constructs.

[Filip Wiesner]

But it seems to me that you are talking about runtime analysis of parameters but what Zoltan mentions is static analysis of some composable function. So Compose considers this function with unstable parameter skippable even before actually running it.

[Zoltan Demant]

Cool, I wasnt aware of that @mcpiroman! Are you sure it doesnt also happen during static code analysis? If that were the case, I guess this could make some sense. The list is created in the same module using Array<out T>.asList()

[mcpiroman]

I'd assume at compile time, the `List<>`parameter, even though displayed as `unstable`is actually considered 'possibly/runtime stable'. And because other parameters are stable, the function is considered and compiled in a way it may both be skipped and restarted, but whether it actually does so at runtime is determined also by the hidden stability bitmask parameter.