Move to Kotlin Symbol Processing?

[ScottPierce]

Have you thought about moving to Kotlin Symbol Processing as a way to work around the library with the compiler api you are encountering?

https://kotlinlang.org/docs/ksp-overview.html

[ForteScarlet]

Hi. I did actually intend to use KSP in the earliest days, but I found that the content generated by KSP seemed to be required as a separate file/class (i.e. it couldn't directly change the original class), which was different to what I needed at the time, so I ended up going with the compiler plugin.

KSP might indeed be a good option though, and perhaps I'll try to provide an additional version of KSP when I have time. But with my limited abilities this probably won't be soon 😣

[lppedd]

Guess this one can be closed too. There is no way to accomplish what this plugin has to do with KSP.

[ForteScarlet]

Guess this one can be closed too. There is no way to accomplish what this plugin has to do with KSP.

KSP enables extensions to the outside world without tampering with the original definition, but comes with some problems, such as calling functions becomes more difficult (especially for Java on the JVM)

For example:

interface Original {
    suspend fun run(): String
}

// The functions generated by KSP

fun Original.runBlocking(): String = runBlocking { run() }

But of course, it's impossible to get KSP to achieve full consistency with the compiler plugin.

After #93, KSP could theoretically collect and share configuration information such as transformers at a relatively low cost.
BUT, as you say, the compiler plugin really has nothing to do with KSP itself—they belong to different topics.

Therefore, we have no plans to provide KSP implementations at this time either. This issue will be closed for now, if anyone has a pressing application scenario, a better suggestion, or can help me (👈 most expected 😚), please feel free to comment~!