Thought on internals: I see that during composition, there is static variable

currentComposer

used; this is probably referenced by the Compose plugin as it transforms @Composable functions. (global variables are evil 😉 ) Wouldn't it be better to omit magic code transformations, and follow style of Kotlin coroutines which are implemented purely as library (except of compiler

suspend

keyword)? Coroutine builders pass

CoroutineScope

as receiver parameter to body of couroutine, and there is no hidden magic behind this, we can study all state of coroutine in debugger. Instead of global

currentComposer

variable, Compose would work on a composer build state as normal reveicer variable into

@Composable

function . Do Compose designers fear that developers would mess with the build state and make more mistakes, or want hide implementation, or what's purpose of this rather complicated implementation wich needs special plugin and reworked Kotlin compiler?

Hi @Michal Bacik, I want to recommend this talk on Android Dev Summit 2019 if you haven't seen it yet

Thanks, I'll have a look.

The talk by Leland answers most of your questions really well

note that my talk is given as if this currentComposer global var doesn’t exist… because it won’t for long. it was always seen as a “temporary solution”, where threading the composer through as a parameter was the intent. getting the compiler to work like we want in this case is not a small amount of work