Just wondering, since it's now recommended to use `mutableIntStateOf()` instead of `mutableStateOf&l...

# compose

[Peter]

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?

[shikasd]

We try to avoid compiler magic when possible.

[romainguy]

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?

[shikasd]

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.

[romainguy]

It could be incorrect to auto box in case you grab references and attempt identity checks for instance

[shikasd]

Ah, you are right

[romainguy]

But also what you said :)

[Karthick]

Will there be a animateFloatAsState and other functions replacement for the primitives?. Since it is returning State<Primitive> instead of PrimitiveState

Same for Animatable<>?

[shikasd]

@Andrew Bailey had a prototype some time ago, not sure if it was abandoned or not

[Andrew Bailey]

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 🙂