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

Peter

12/07/2023, 9:40 PM
Just wondering, since it's now recommended to use
mutableIntStateOf()
instead of
mutableStateOf<Int>()
. Why can't compose compiler do that conversion on it's own behind the hood?
s

shikasd

12/07/2023, 9:46 PM
We try to avoid compiler magic when possible.
👍 3
👍🏾 1
r

romainguy

12/07/2023, 10:32 PM
Also to this right wouldn’t we need to inspect how the value is used to guarantee it’s not being used as an object anywhere?
s

shikasd

12/08/2023, 2:08 AM
It does not matter as much, I guess? Technically it could result in more boxing, but at the same time usually it is still better to update, that's why we added a lint rule that just straight up recommends it. I think the main reason is just that it is a pretty involved transform that kinda asks for a separate compiler plugin, and also breaks debugging in case you want to step through getters/setters.
r

romainguy

12/08/2023, 2:17 AM
It could be incorrect to auto box in case you grab references and attempt identity checks for instance
s

shikasd

12/08/2023, 3:23 AM
Ah, you are right
r

romainguy

12/08/2023, 3:23 AM
But also what you said :)
k

Karthick

12/12/2023, 5:34 PM
Will there be a animateFloatAsState and other functions replacement for the primitives?. Since it is returning State<Primitive> instead of PrimitiveState Same for Animatable<>?
s

shikasd

12/12/2023, 5:58 PM
@Andrew Bailey had a prototype some time ago, not sure if it was abandoned or not
a

Andrew Bailey

12/12/2023, 6:36 PM
Yeah, it's something I've put thought into. And to elaborate,
MutableIntState
implements
MutableState<Int>
(same goes for its other primitive friends), so it should be possible for us to convert to the specialized state types without introducing new or replacement animation APIs. There's more going on with the animation APIs that make it so we can't just drop in the new interface and call it a day, but it's still on my mind. My attention has just been on other things lately 🙂
👍 1
6 Views