TASTY: no way to access variance of parameters of a TypeParamRef type constructor

[neko-kai]

This is a follow-up to #8520

As per @smarter's suggestion in #8520 (comment) there is now a method .typeMembers that can extract symbols for type parameters of a trait/class.

However, there's no exposed way to extract variance information of a type parameter, that is extract variance of parameters of F in trait K[F[+_, +_]]. @smarter describes a way to get this information in his post above:

(If I want the variance of the parameter of F itself, then I need to get the info of F which should be a TypeBounds whose upper-bound is an HKTypeLambda, once I get that I can finally call HKTypeLambda#declaredVariances on it.)

Right now I implemented the above procedure by accessing hidden methods TypeParamRef#underlying and HKTypeLambda#declaredVariances using Java reflection. (current usage)

But it would be great if Quotes interface exposed these methods non-reflectively, so that I could drop these workarounds. Thanks!

[bishabosha]

@nicolasstucki @Kordyjan it seems the underlying internal compiler API changed (HKTypeLambda#declaredVariances) so now all Izumi-reflect based projects (e.g. ZIO) are potentially broken on 3.3.0 - see softwaremill/realworld-tapir-zio#107 and zio/izumi-reflect#391

[nicolasstucki]

@neko-kai to make sure we support the use-cases of needed in izumi-reflect we need a small example of the definitions you would write and the information that the macro would extract from the definitions.

izumi-reflect uses java reflection to access declaredVariances in 3.3.0, this is an unstable API that can change in any subsequent version 3.3.X or 3.Y.X. For 3.3.0 will probably be broken unless another workaround that works for that version is found (using java reflection).

To make the 3.3.X version of izumi-reflect we can add declaredVariances to 3.3.1 as an experimental. This means that izumi-reflect will be able to use java reflect to access the declaredVariances of the reflection API in 3.3.1+. This does not fully guarantee the stability of the API, it would be a middle ground between the current solution and a solution without java reflection in 3.4.0+.