IssueTracker

Is this fixed ?

I tried this with same Compose version but new AS (2021.1.1 Beta 4), it does not recompose Child2

Lists in Kotlin are not (yet) truly immutable. They're regular Java lists behind the scenes and can be mutated by casting to a Mutable list. Could that be the reason why?

A List<T> is not inferred as immutable because, for example, mutableListOf<T>() is also a List<T>. List<T> restricts the receiver from modifying the list (e.g. it is read-only) but does not imply the list is immutable as it can change at any time through a MutableList<T> typed reference.

Even though this is working as intended, I am keeping this issue open as we need to provide a solution here as using a List<T> as meaning an immutable list is a common pattern.

I tried to annotate a fun with @Stable but apparently it had no effect on the list parameter. Is this expected?

For me it was unexpected, as I thought I could force the compiler to just accept that it's stable.

Marking fun as stable does not mark it's parameters as stable. For possible workaround you can check the article from Chris Banes here: https://chris.banes.dev/composable-metrics/

I do agree that it would be nice if we could directly mark composable fun's parameters as stable, but the @Stable annotation can only be applied to classes and functions for now. It would be a good workaround for types from outside our module (external library for example). Compose cannot infer their stability and we have to do this tedious stable holders for those. Marking fun parameter as stable directly would be much simpler

I'm closing this issue as working as intended. We cannot mark List<T> as stable since it has no such guarantees (unfortunately). Please keep in mind that "i'm not allowed to write to this object" is not the same as "this object will not change".

It is likely that we will end up skipping simple cases like in your example above where we can analyze back to the variable initializer where the value is using listOf, however we will not in general skip a function parameterized with List<T>.

I imagine Google could assist in "stabilizing" Jetbrains' ImmutableList/PersistableList design and then treat those as @Stable.

For the time being it's straightforward to extend Jetbrains' API to create your own StableImmutableList and use that in your code pervasively, if you're able to put up with pre-release status.

As this article explains, using KotlinX immutable collections is a solution. These types are interpreted as immutable by Compose. However I'm not sure what version of Compose is required. I'm using version 1.2.0 of Compose compiler.

comment#10: Yes, but sadly the immutable collections stable treatment is just a few undocumented hacks for one or two classes. Zero guarantees. See https://issuetracker.google.com/issues/238057117

comment#11 I get that supporting only few types isn't a perfect solution, but "few undocumented hacks" seems like an rant of sorts. Just state in your issue that others are missing and wait for response. No need to be mean.

A user is still better off using their own explicitly stable flavor of these kinds of collection types instead.

For me immutable collections is the problem solver in the 99% of the cases. List is by far most used collection type in compose parameters in our codebase.

This is inconsistent, confusing, and counterproductive. I am clueless why this is the case, looks like someone just hacked up a bit of stable treatment for a couple of types they could think of.

I'm pretty sure Collection does not not give a guarantee about order of items, which might be unstable behavior for compose and i fully agree with that, but it's just a shot in the dark.

Switching to a completely different collection type seems an overkill and it's actually going against the intended purpose here (purpose is to improve the performance, but having to convert all standard lists returned from map/filter methods into those collections actually downgrades the performance slightly).

https://issuetracker.google.com/issues/218088931 or ability to mark composable functions as @Stable seems much better way. Yeah it does not guarantee that some developer will not pass mutable list and mutate it later, but if team agrees to only pass immutable lists to the compose, it's probably a better way of doing it.