At this point there is no decision nor active discussion about an alternative for
scala-reflect in Scala 3.
There are opinions that:
- Reflection is not important, everything may be done at compile time
- All the use cases for reflection can be satisfied by a macro
At the same time many projects rely on
scala-reflect at the moment. Among these projects are Spark, doobie, etc, etc.
Also not all the reflection usages can be covered in compile time. Our project, distage – a module system with a solver and garbage collector (or a DI mechanism if you prefer) – represents instances required for an application as a graph and reshapes the graph according to user input.
Across all the reflections APIs two things have the highest importance: equality check (
=:=) and a subtype check (
I’ve tried to implement a macro plus a runtime to re-implement these basic operations and got it working. My model is not perfect but despite the belief that subtype check is deadly hard to implement, it’s good enough for many practical purposes. But, unfortunately, I cannot make it perfect with just a macro (I don’t have enough data to provide complete support for path-dependent types).
I’ve described my experience in an article. That experience is kinda controversial - the model works and it’s just 2K LoC. But it’s kinda complicated and relies on several unspecified behaviours in macro APIs. So I don’t think that custom macro-based approach is a right way to go.
Despite all its implementation issues
scala-reflect is a very attractive and important feature for many engineers and companies.
So, I wish to try to initiate a discussion about implementing a sane alternative to
TypeTag in Scala 3. Of course it shouldn’t expose internal compiler data structures and implementation details, should be type-safe and sound. But feature set may be significantly reduced also. Just equality and subtype checks would cover more than a half of reflection usecases.
Also I’ve created a ticket for this.