I realize why mutableIntStateOf needs to exist bec...

# compose

[Jon Bailey]

I realize why mutableIntStateOf needs to exist because of auto boxing, and why it's not done "magically" by the compose compiler. But I'm curious why it's not an overload of mutableStateOf like so (simplified):

fun <T> mutableStateOf(value: T)
fun mutableStateOf(value: Int)

[shikasd]

We explored both options, compiler magic is just complicated to debug, so we try to reduce it where possible
The overload variant also had some drawbacks behind it, for example you couldn't create a boxed version if it was more suitable for perf profile. Primitive version is great, but it could result in more boxing if you return this value from a lambda, for example

[Jon Bailey]

wouldn't it be possible to create the boxed version by doing mutableStateOf<Int>(0) ? Also do you mean return this value from a lambda like using it inside remember?

[Jon Bailey]

(not questioning the decisions just it's nice to understand it 😊)

[shikasd]

Remember is inlined, so it is fine for this case, we were mostly concerned about lambdas used for animations and modifiers
@Andrew Bailey might have more details, I wasn't really part of that conversation

[Jon Bailey]

ah ok thanks, appreciate the insights!

[Andrew Bailey]

Yeah, we considered it. As nice as it would've been to remove autoboxing for you for free after an upgrade, it had some drawbacks where it made more sense to make it a manual opt-in.

A big one has to do with how you use the state. We made MutableIntState extend MutableState<T>, which means you can call .value on it and still get correct behavior. But if you do and you're using the primitive version, it'll box for you on the spot which can actually cause more autoboxing than using the generic API. Theoretically the compiler plugin could've fixed that, but we decided against it since it's too magical of a behavior.

Another detail is for libraries. Changing a public return type from MutableState<T> to MutableIntState is no problem but you can't do the opposite without breaking API compatibility. It makes more sense for this to be explicit in case a library is using inferred types in public API. The syntax to opt-out of this would have been clunky, and if you forgot and then later decided you needed an equality policy, your options would have been limited.