SwiftUI uses

@State var count = 0

while in Compose,

val count = +state { 0 }

. Why such a hacky thing (

+state

) is chosen?

In compose, you can as well use

@Model
data class CountModel(var count: Int = 0)

The

+

is the syntax for effects, which is subject to change, but essentially it's main purpose to give Compose knowledge about some building blocks that are not UI, so runtime can memorize and reuse it or call in at specific moments, such as compose lifecycles

But why?

Why not var?

Yes, like

var count = 0

Try to type the latter 🙂 But with +

I just don't understand why in Kotlin there is a hacky thing such as prefixing a plus sign.

This is definitely subject to change, API still has a long road to be finalized, so things will change, including how Effects are being created in composition

Not 100% set in stone yet, but i’m fairly certain the plus operator is going to go away. That said, I believe the use of functions for state (and other things we currently call “effects”) is more composable than annotations like in swiftUI can be. It will very likely be

val count = state { 0 }

and

var count by state { 0 }

will also work if you prefer that (basically, current API just without the + being needed)

I'm looking forward to the property delegation part 🙂

the code is there for that to work already. We just need to rebase the compiler to get property delegation compiling properly. CL is up, close to getting merged

Are you going to make milestone/preview/dev/pre-alpha/whatever releases at some point for us to try more easily, knowing it is in a sufficiently working state (as opposed to current state where you might sync the repo in a non working state, and can't know when it works again or if you should checkout an earlier commit you don't know)? I'm not asking for compatibility between those versions, just releases with a name/number that I can conveniently download and try using Compose to get a sense and of what's coming, and maybe a little experience.

once it's ready for that, yes. It'll follow the same alpha/beta/rc cycle as the rest of the androidx libraries

I'm not talking classic alpha and all, but more preview. Something like weeklies, so it makes it easier to know what preview version you're using as an early previewer.

probably. We're not there yet though. 🙂 The dependencies on a modified kotlin plugin and android studio make that sort of standard snapshot a bit less useful. Once we can get it integrated into a more normal workflow it'll get easier.

Maybe @pavi2410's point is the

@State

annotation is clearer than using a

+

to denote a UI state variable.

I am OK with the use of property delegation. But if there is an annotation, it might require reflection at runtime 🙃

An annotation would not require reflection at runtime; we are a compiler plugin and process all of our annotations during compilation. Using an annotation has some advantages. For example, using

+memo

requires realizing that you're supposed to also specify an invalidation set of all the parameters used to calculate the memoized expression. If you miss one, your code will be subtly wrong. Using an annotation instead would allow the compiler to calculate the invalidation set of the expression, thus avoiding bugs. This has been the topic of a few hallway discussions; it's potentially a space worth exploring further.