# compose

Zoltan Demant

08/11/2022, 11:06 AM
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?
Copy code
restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun BottomBar(
  unstable pages: List<ExplorePage>
  stable currentPage: ExplorePage
👀 4


08/11/2022, 11:11 AM
Maybe you could use Kotlin’s Immutable Collections to make the parameter stable. Check this out for more info: My bad, I misread the post 😬

Stylianos Gakis

08/11/2022, 11:12 AM
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

08/11/2022, 11:16 AM
I just had to verify that its actually being skipped, and it is mind blown

Csaba Szugyiczki

08/11/2022, 12:32 PM
Are you actually “using” the pages parameter, or just pass it down to another Composable?

Zoltan Demant

08/11/2022, 12:34 PM
Yup, Im using it in the same composable!


08/16/2022, 12:27 PM
AFAIK compose uses even more magic, to track down some possibly stable parameters at runtime (via bitmasks). So that if you a parameter of
, it is unstable at compile time, but when you directly pass an argument of
, it knows that the returned list is immutable and may consider that single invocation of a function as skippable.
Though that feature is likely very limited ATM and only supports some stdlib constructs.

Filip Wiesner

08/16/2022, 12:52 PM
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

08/16/2022, 2:17 PM
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()


08/17/2022, 7:39 AM
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.