Why_not_move___Compose_to_language_level__as_you_already_do_some_byte_code_changes_with_compiler_plugin__I_mean_maybe_something_like_this_will_be_better_.kt

I would say because adding a language feature requires a lot of work, careful planning and bierocracy bureaucracy XD, and having it as an annotation is just fine for the uses of a single domain.

It's a compiler plugin. In some other languages those can create first class language support.

bierocracy

Love that word 🍻 😆

compose fun

doesn't mean anything. Functions are already composable building blocks, there's nothing you can add here. While

@Compose fun

screams at you: 'SOME BAD CODE RIGHT HERE! There's some reflection/codegen/transformations because abstractions are done wrong!' Thus, annotation is significantly better here.

For reference, there's no reflection involved in the

@Composable

annotation. There are codegen/transformations though.

I know. But ideologically it is the same thing: implicitness and indirection.

On React for Kt, they use

fun RBuilder.button()

. Something like

Composable.Button()

might have been considered, but I am not sure if it works well for codegen. I guess the compiler is doing some optimizations and create some template functions like Ivy (Angular). Will the IDE be able to know that we are in a

@Composable

or not, and allow or disallow some code?

Well, maybe no, as Android Studio (IDEA plugin) looks abandoned.

@Tristan Caron I think that just extension function not work for Compose, the annotation generates much more things that just a new argument in a function. You can read this blog post from Leland Richardson to understand compose from the first principles http://intelligiblebabble.com/compose-from-first-principles/

Will the IDE be able to know that we are in a

@Composable

or not, and allow or disallow some code?

Yes, this already mostly works. You can't call composable functions from outside a composable function.

Would it be fair to compare

@Composable

with something like

#[derive(Composable)]

? https://doc.rust-lang.org/1.15.1/book/procedural-macros.html So, maybe instead of introducing a new keyword just for compose, maybe it could be interesting to make codegen something integrated to Kotlin compiler. I don’t really know how it works today, but my guess is, if we want to use code generation, we have use an external lib, and run something like

gradle codegen

as much as it’s necessary. But for

compose

, it’s doing codegen on its own, and we have to use a plugin to ensure a good development experience.

Why bring so much complexity? In my opinion, general purpose programming languages like Kotlin shouldn't bend to a framework's needs.

In a way, it is integrated with the Kotlin compiler - it's a compiler plugin. So there's no need for separate tasks - you just compile your code like you normally would and it works.

Kotlin does not bend it’s knee to the framework, there should be no argument around this.