A modern programming language that makes developers happier.

kotlinlang

How can a function with unstable values be *restartable &amp; 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&lt;ExplorePage&gt;
  stable currentPage: ExplorePage
)```

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

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

My bad, I misread the post :grimacing:

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.

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

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

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&lt;&gt;`, 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.

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

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.

Cool, I wasnt aware of that <@U01T5JTQG4B>! 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&lt;out T&gt;.asList()`

I'd assume at compile time, the `List&lt;&gt;`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.