There are a few reasons I opted to go in this dire...
# compose
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
@Composable(version=2.0, target="whatever")
. • There really wasn't any benefit to making it a keyword, only downsides relative to an annotation.
👍 38