- Only top level class, object, property or function can be @Given declarations
@Given fun <T> et(@Given eq: Eq<T>): Eq<Tree<T>> = ...- Declarations with Value parameters annotated as @Given for injection must
2.1 Generate an additional internal function of the same shape where the value parameter has a default value to given()
internal fun <T> et(eq: Eq<T> = given(), unit: Unit = Unit): Eq<Tree<T>> 2.2 Replace function calls for the generated function and all given() calls by the instance found
val treeIntEq: Eq<Tree<Int>> = et<Int>()2.3 Export exclusively the non-generated function where value arguments have no default values
//3rd party code depending on lib exporting Eq for Tree and Int
et(intEq) //ok because explicit to non internal//3rd party code depending on lib exporting Eq for Tree and Int
et<Int>() //only ok if user is using compiler plugin In the second case the compiler plugin has detected all generated internal functions from a previous compilation and has made them public. If the user is not using the compiler plugin only has access to manually passing arguments to construct any dependencies.
The given function is another example of this same behavior.
@Given fun <A> given(@Given ev: A): A = ev
This also is a polymorphic function the user can define but calls to it can't be exported in function bodies.
The main issue is that given() or similar lookup expressions can't be exported in function bodies of polymorphic functions unresolved. If they are exported the program would crass because the IR tree instrumentation does not have access to instrumening function bodies coming from remote already compiled libraries like in the case of the JVM jars.