Weeks ago, I came up with an idea for a simple Kot...

# compiler

[Mohammad Fallah]

Weeks ago, I came up with an idea for a simple Kotlin compiler plugin to solve the prop-drilling problem in Compose.

In practice, many of our composable functions are private and usually called only once, often just to wrap something in a Box or similar. But this forces us to pass parameters down through three or four functions. The result is unnecessarily bloated function signatures. The real pain comes when you need to add a new parameter to the deepest composable — you end up modifying five or six functions just to thread that value all the way down.

My idea was to annotate the child’s parameter with @arg. A class would then be generated for that function’s arguments, which you could reference in its parent. The class would act only as a marker and get replaced by the actual parameter at compile time. (I’ve attached an image to illustrate this.)

Unfortunately, I gave up on the implementation. The compiler plugin API is poorly documented, and the solution felt fragile — I worried it might easily break with the next Kotlin release. So, I decided to share the concept instead. Maybe someone in the community with deeper knowledge of compiler internals can pick it up and turn it into something stable. (it's not the whole solution and there are more that I'll share if someone is interested)

[eygraber]

Why not use a CompositionLocal or context parameters?

[Mohammad Fallah]

because I don't want to make it too much implicit with CompositionLocal, and context parameter doesn't sounds very good for this use case to me.

[theapache64]

@Mohammad Fallah have you seen this

talk▾

by @bnorm. If not, i’d suggest watch it before giving up… 🙂 It covers what all APIs are available and its usecases and also some great examples you can look online

[Mohammad Fallah]

@theapache64 Thanks for the suggestion, that’s the exact talk that left me disappointed 😅, because in the last minute Brian basically goes, ‘yeah, this will probably never be stable.’ 🫠

[theapache64]

oops 😄 i got better clarity after watching it 🫠 i’d say you should give it a try despite that callout, because i just started working on my first compiler plugin (using the ir backend)… and while it’s a little intimidating with so many apis, it’s really fun building a compiler plugin… 🙂

[Mohammad Fallah]

That was great!
I’ll rewatch the talk and start with some simple stuff, it looks really fun.

[shikasd]

I think the main problem is not stability, but lack of proper interactions between compiler plugins, e.g. you cannot ask Compose compiler to be applied after your plugin which can lead to subtle bugs

[shikasd]

I usually suggest to manually roll props into classes if the updates are not too frequent

[CLOVIS]

This is one of the use-cases for the dataarg proposal, but it's not on the roadmap yet

[Mohammad Fallah]

Yes, I think I first heard about it at KotlinConf 2024, and it sounded really cool.
It’s a pity it didn’t continue.

[CLOVIS]

It's still an idea the team talks about semi-recently, it's just not the top priority for now; I discussed it with them at KotlinConf 2025

[Mohammad Fallah]

Oh, that’s great to hear. I thought it had stopped completely,
I really hope we can have it soon.

[CLOVIS]

I don't think it will be before 2027 at least, context parameters and rich errors are coming first