Weird question. Is `remember { ... }` equal to `remember(Unit) { ... }` ? Or does the `Unit` key ove...

# compose

[Filip Wiesner]

Weird question. Is remember { ... } equal to remember(Unit) { ... } ?
Or does the Unit key override the implicit key derived from call order? Am I just overthinking things?

[FunkyMuse]

https://developer.android.com/reference/kotlin/androidx/compose/runtime/package-summary#remember(kotlin.Any,kotlin.Function0)

[Filip Wiesner]

So I guess the answer is: Yes, it's the same and yes I am overthinking it 🙂

[Chuck Jazdzewski [G]]

They have the same result but remember { ... } is more efficient as it doesn't needlessly store Unit in the slot table and compare it. In both cases remember can be thought of as implicitly having a key that is its position in composition (the inspiration for the the name "positional memoization"). Adding a key to remember does not replace the positional key, it adds to it to form a composite key that when the composite key changes the lambda is reinvoked to produce a new value.

[FunkyMuse]

@Chuck Jazdzewski [G] so the key inside remember is basically a primary key that is added by the compiler, if you provide an additional key yourself then it becomes composite key, something like in an SQL database?

[Chuck Jazdzewski [G]]

Yes; that is the idea. The positional key is implied by the location where the remember appears in the composable function call graph. Since the slot table stores a linear record of the call graph, the location in the slot table is sufficient to determine which remember is being referenced.

[Filip Wiesner]

Thanks for detailed answer, Chuck 👍 I really appreciate it. Now it seems like my question wasn't as stupid as I thought 😅