The compose compiler treats compose functions in much similar way the kotlin compiler does to suspend functions. Correct? My curiosity is, why did the Compose Dev team decide to go with annotations (i.e.
) instead of making compose a reserved word, similar to suspend functions?Knowing this was much influenced by JB, if the annotations approach seemed more convenient, why didn't they go with it for suspend functions? (i.e
I was assuming the
keyword could have been reserved for UI function in each platform
I think a big factor here is that Compose is compiler plugin with a separate runtime and not embedded into language
Whereas suspend functions are processed by Kotlin itself on many levels
2 years ago
There are a few reasons I opted to go in this direction:
• Back in the day (the very early days of Compose), I had my own syntax for calling composable functions, and I desperately wanted to be able to infer the
annotation, making it optional or eliminating it completely. Making it optional/deprecated in the future is more difficult if it is a keyword. We eventually made some design changes that made it not possible/practical/useful to get rid of the annotation, so this reason is now an artifact of the past.
• Using a keyword is a language-level parser change. This means it would break things like linters and tools. Using an annotation claimed less language-level real estate. Jetbrains created Kotlin, so they can make language changes (to support suspend functions) more easily than we (Google) can. As a general rule of thumb though, we try to make Compose as noninvasive as possible and this includes limiting language changes.
• Suspend functions were created in a different time. At the time suspend functions were invented, the IR Backend didn't exist, meaning that implementing suspend functions couldn't be done without intense compiler changes anyway. If Jetbrains were to re-invent suspend functions today, I wonder if they would choose annotations+plugins instead.
• Using an annotation gives us options to pass parameters to the annotation which is potentially useful for future API space
• There really wasn't any benefit to making it a keyword, only downsides relative to an annotation.