Is there a proposal to bring in the compose-runtim...

# language-proposals

[xxfast]

Is there a proposal to bring in the compose-runtime compiler plugin capabilities to the language itself?

[hfhbd]

Which capabilities do you mean?

[franztesca]

The facade you can achieve with context receivers:

context(MyComposable)
fun Something() {
    // Use MyComposable DSL here
}

but compose does a lot of stuff more under the hood AFAIK (adding code in each composable function, detecting immutability/stability of arguments, etc.) for which I don't see how they'd fit in the language

[Javier]

context is sugar to passing the composable as normal argument to the function, so what would you expect there to be different to what you have now with the difference of using this instead of the argument name?

[franztesca]

Fundamentally, @Composable is sugar for passing a Composer as normal argument to the function. Plus it's a marker for the compiler to do additional tricks (such as instrumenting the function).
Not much different from suspend keyword, which is sugar for passing a Continuation as a normal argument to the function. Plus a marker for the compiler to implement the state machine for suspension.
If you need some compiler magic (like instrumenting the function or making a state machine), then you need a compiler plugin. If you just want to create a DSL for a specific co-effect (which both Composable and suspend are) and do not need compiler tricks, then you can use context receivers. An example is Arrow's Raise<>, which creates a DSL for typed co-effect-based error propagation/handling.