Is there a way to mark a parameter of type `List&l...

# compose

[molikto]

Is there a way to mark a parameter of type List<String> as stable?

[Adam Powell]

it's not stable though 🙂

[Leland Richardson [G]]

the short answer is “no, not really”. But can I ask you to elaborate more on why you want to? I’m curious about how this type of thing manifests in the wild and would like to understand it more

[Leland Richardson [G]]

in the future, for instance, it might be possible for us to infer certain patterns as stable (for instance, listOf("foo", "bar")

[Leland Richardson [G]]

but right now we can’t do that safely for a variety of reasons

[Adam Powell]

ModelList might be a solution here, depending

[Adam Powell]

but I assume we don't have a readonly interface type for it (yet?)

[Leland Richardson [G]]

no. List is read-only but not stable but we figured that would be good enough

[Leland Richardson [G]]

but i don’t think that List<String> being stable should be a requirement for correctness

[molikto]

I don't really have a valid case for this, except for my desire that more calls be cached, but in practice there might not be any performance difference (or there are cases it is worse performnace?).

[Leland Richardson [G]]

it can go either way but if there’s a chance for all parameters to compare true with previous versions, then generally it will be a performance win

[Leland Richardson [G]]

but my recommendation to you would be to not worry about it until it is an actual problem

[Leland Richardson [G]]

for instance if you’re passing these strings into some other composable somewhere, Strings are stable and then you might get some good skipping happening at those call sites

[Leland Richardson [G]]

in the long run we want to gradually make things smarter so that this can happen a higher percentage of the time

[Leland Richardson [G]]

but we would like for it to be something that you just don’t really need to worry about in most cases

[molikto]

Agreed, I think most of time it doesn't mater that much, because all the heavy-lifting happens inside widget-API

[molikto]

If it really matters, one can always use a wrapping Stable class... so I guess I am just nitpicking

[Leland Richardson [G]]

yeah especially as we improve performance more and more, my hope is that we can just recommend to not worry about this in user-land. You’re right that the heavy lifting happens below widget-level APIs in most cases. That said, there will no doubt be cases where this does make or break whether a certain API in user-land is sensible, and we are definitely trying to think about the right way to tackle this problem

[Leland Richardson [G]]

i really don’t want to see @Stable annotation sprinkled over almost every type in user-land though

[Leland Richardson [G]]

ideally kotlin at some point can provide some notion of immutability that we can rely on from a more language-level ecosystem standpoint

[molikto]

thanks!

[Zach Klippenstein (he/him) [MOD]]

ideally kotlin at some point can provide some notion of immutability that we can rely on from a more language-level ecosystem standpoint

This would be awesome, but this seems very unlikely anytime soon. It would probably require a better notion of immutability on the JVM or value types or something wouldn’t it? I haven’t been following the progress of Valhalla too closely but I would think it’s quite a ways off for android use.

[Leland Richardson [G]]

correct, for some definition of “soon” lol

[Leland Richardson [G]]

there’s a lot of different avenues here, but basically i want us to be cautious about creating a world where @Stable is sprinkled all around the entire ecosystem

[Leland Richardson [G]]

at least without thinking carefully about it first