https://kotlinlang.org logo
#compose
Title
# compose
m

molikto

04/23/2020, 1:40 PM
Is there a way to mark a parameter of type
List<String>
as stable?
a

Adam Powell

04/23/2020, 3:16 PM
it's not stable though 🙂
l

Leland Richardson [G]

04/23/2020, 3:25 PM
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
in the future, for instance, it might be possible for us to infer certain patterns as stable (for instance,
listOf("foo", "bar")
but right now we can’t do that safely for a variety of reasons
a

Adam Powell

04/23/2020, 3:36 PM
ModelList
might be a solution here, depending
but I assume we don't have a readonly interface type for it (yet?)
l

Leland Richardson [G]

04/23/2020, 4:07 PM
no. List is read-only but not stable but we figured that would be good enough
but i don’t think that List<String> being stable should be a requirement for correctness
m

molikto

04/23/2020, 4:09 PM
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?).
l

Leland Richardson [G]

04/23/2020, 4:13 PM
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
but my recommendation to you would be to not worry about it until it is an actual problem
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
in the long run we want to gradually make things smarter so that this can happen a higher percentage of the time
but we would like for it to be something that you just don’t really need to worry about in most cases
m

molikto

04/23/2020, 4:16 PM
Agreed, I think most of time it doesn't mater that much, because all the heavy-lifting happens inside widget-API
If it really matters, one can always use a wrapping Stable class... so I guess I am just nitpicking
l

Leland Richardson [G]

04/23/2020, 4:20 PM
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
i really don’t want to see
@Stable
annotation sprinkled over almost every type in user-land though
ideally kotlin at some point can provide some notion of immutability that we can rely on from a more language-level ecosystem standpoint
m

molikto

04/23/2020, 4:24 PM
thanks!
z

Zach Klippenstein (he/him) [MOD]

04/23/2020, 8:25 PM
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.
l

Leland Richardson [G]

04/23/2020, 9:10 PM
correct, for some definition of “soon” lol
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
at least without thinking carefully about it first
2 Views