Eva

A related question is should we keep the abstraction built around it. I'm leaning towards yes, as we may investigate the plugin api https://youtrack.jetbrains.com/issue/KT-49508 when it becomes stable.

My understanding is ksp is a wrapper of the unstable frontend compiler api. I do want to explore integrating with that api directly if there's something stable as it could...

Anyway it was the kapt abstraction that was a pain because it had to deal with parallel java & kotlin metadata models. The ksp one is just a thin wrapper...

There _may_ be some gradle hackery to make this work, but it's not something I really want to explore, I've done enough of that in the past. If someone else...

The currently plan is to not include any anvil-like features to keep things simple and flexible but allow something like anvil to be built on top. Note: map keys are...

In fact I don't think there's anything blocking someone making an 'anvil' for `kotlin-inject` right now, it should already support multiple rounds properly. You would just be generating the `@Component`...

> but I dislike that it's not really integrated with the native dagger Can you elaborate on that? In my mind it would be just as easy as adding another...

Note that Hilt is implemented in much the same way as Anvil as a separate code generator, really the only difference is that it's first-party in dagger where anvil is...

Interesting idea! One thing to note is that I'm leaning towards suggesting to use inheritance for combining things like you would with modules whereas component dependencies would be used when...

One thing is default values you declare should probably be propagated, so you could do: ```kotlin @Component abstract class MyComponent(@Component component: NoArgComponent = NoArgComponent()) MyComponent::class.create() ``` at least