it’s not an AST -> AST transformation, far from it

it has runtime information about the files and classes you’re talking about because they’re preloaded in the classloader

even if kapt is run at pre-compile time

kapt can only do codegen, but never modification or destruction of the original fine

furthermore, if you try to cheat and do it using filesystem APIs compilation fails afterwards IIRC lol

still, getting info about types you can't use is better than nothing which is the current state of the art.

I don't understand, if it's run at compile time, why does the end target matter ?

the kapt processor is written in java, so your "macro" code can use whatever you like from the jdk

as long as what you spit out is kotlin code

scala.js can use macros right

Also on a different note, I want to use

Show

to generate nicer messages when assertions fail. So users can provide better string representations of custom classes. What's your recommended way of discovery? Two options spring to mind for me - SPI or having the instances live in a pre-defined package and using Class.forName. Another problem is I don't know what to do for Show<List<String>> in either of those ideas

You can use the arrow type classes to generate the show extensions for all the types.

when you declare for example:

@extension
interface ListKShow<A> : Show<ListKOf<A>> {
  override fun ListKOf<A>.show(): String =
    toString()
}

you get for free at the package level

.show()

so essentially anyone providing an extension likes that gets show syntax for any projected data types

you can also have dependecies

when declared abstract become arguments

for example in that extension you can require the

Show<A>

and the user can inject it or implicitly get it through delegation via constructor

But I can't call .show() in kotlintest because I don't know what the types are

all I have is an Any?

Then you can define your own type class like show which your users implement when they construct the test and pass the dependency in the constructor or similar

Then you make the test implement the typeclass via delegation

at the point you can rely on your users providing you a valid

Show<A>

for the type they are testing which allows you to call

show()

You can also already express dependencies on Show under that assumption.

For example:

fun <A> Show<A>.prettyPrint(a: A): String =
  a.show()

that is a dummy example but you can rely on type classes being in scope by declaring them as receivers

then whenever they are implemented elsewhere their syntax is transparent to usage and you don't need to prefix

prettyPrint

or having your scopes provide their syntax:

class CustomScope<A>(SA: Show<A>): Show<A> by A {
    ... a.show()
}

Ok so if you have

data class Person(name: String)

and you write a test like

person.shouldBe(Person("sam"))

I want to have a better to string for person.

You're saying I have to invoke

person.shouldBe(Person("sam"))

inside the scope of a

Show<Person>