Forgive me if this is already talked about, but seeing as `@Composable` is a type similar to `suspen...

# compose

[Fredrik Larsen]

Forgive me if this is already talked about, but seeing as @Composable is a type similar to suspend and not an annotation, can we except composable fun foo? In that case, what about @Preview? And while we're at it, is the unary plus override going to change? Thank you so much for this massive undertaking. Really exciting times. 🙂

[Fudge]

Regarding unary plus, it’s getting removed.

[Fudge]

I think having composable as an annotation makes sense, just like we have @Serializable from the other compiler plugin.

[Fredrik Larsen]

You might be right. I'm not a big fan of reusing the annotation syntax. As it becomes "magic".

[Fudge]

And how does being a keyword make it less magic?

[Fudge]

Just to be clear, originally annotations in Kotlin didn't require an @ and had a convention to be camelCased, so it's not so clear cut.

[wasyl]

Afaik there’s no functionality in Kotlin that allows adding keywords from plugins, and it wouldn’t make much sense to have composable keyword in Kotlin itself

[karelpeeters]

Well compose is already using a compiler fork, because the current plugin system is too limited anyway.

[Adam Powell]

It's not a fork, the extension points used by the compose plugin have been upstreamed to kotlin master

[karelpeeters]

Ah great to hear, everything I hear/read about compose gets outdated so quickly 🙂

[Leland Richardson [G]]

a keyword would be great, but only if “composable” functions would be part of the kotlin language. A language keyword needs to mean something. While something like that is possible in a distant future, for now we are able to iterate without changing the semantics of the language too much by using an annotation while we figure out exactly what it…. means… and if it is useful outside the scope of UI/android/etc