Scala 3 macro-annotations roadmap?

Hello.

As a library maintainer, I’m interested in leveraging macro-annotations for saving myself and my team some heavy boilerplate related to datatypes. The defacto standard datatype constructs (enum / case classes) are notorious footguns when it comes to evolving librariesin binary-compatible ways, and we maintainers are left high and dry in the face of this problem. Traditional code-generation solutions aren’t ergonomic for a number of reason (require the data definitions from being disjointed for the rest of the code, in particular). This makes macro-annotation solutions quite appealing, at a first glance.

In the context of Scala 3, the fact that macro-annotations are constrained to not change the interface of annotated constructs is, I think, absolutely reasonable. I for one am quite happy to work with that constraint, as it doesn’t make it harder for IDEs/editors to do their job. My favoured solution would be somewhat similar to what @smarter prototyped in [Proof of Concept] Code generation via rewriting errors in macro annotations by smarter · Pull Request #16545 · lampepfl/dotty · GitHub : the advantage is that this type of solution can be implemented in both Scala 3 and Scala 2 to help cross-compilation (if I’m not mistaken).

However, in the context of Scala 3, I’m quite surprised by the necessity of invasively bubbling up the @experimental scope to every single piece of code that transitively calls upon a macro-annotation-expanded construct. The implication is that library maintainers can’t currently use this macro-annotations, as it’d come at the cost of polluting the user-space.

Full disclosure : when I started writing this message, I was about to complain about the invasive nature of @experimental preventing controlled usage. But I think I get it : if libraries count on experimental features for implementation details, the removal of the feature (however underpowered) could mean that library maintainers would be discouraged to continue maintaining. Therefore it’s safer for the ecosystem for experimental features to be invasive.

So I guess my question is as follows : is there any way to know a rough ETA for macro-annotations to go through the SIP process ? Is there a publicly available roadmap for the SIP that would tell us where in the queue it sits ?

2 Likes

So I guess my question is as follows : is there any way to know a rough ETA for macro-annotations to go through the SIP process ?

There is no official ETA for this. I plan to open a SIP in the coming month or two. I have been analyzing the details that need to be included in the SIP but haven’t had time to write them down yet.

The current implementation is feature-complete, but steel needs stabilization and the addition of soundness check on the user generated code. We might change the interface of MacroAnnotation to allow some use cases that are not currently supported. One that comes to mind is the ability to transform the class and its companion object at the same time with a single annotation.

I will try to give a more detailed roadmap the the coming weeks.

5 Likes

Thank you for providing some context @nicolasstucki. It makes the road ahead a bit clearer.

One that comes to mind is the ability to transform the class and its companion object at the same time with a single annotation.

This certainly would be useful !

One that comes to mind is the ability to transform the class and its companion object at the same time with a single annotation.

This certainly would be useful !

Now we know how we will do this. We will work on the implementation in the following weeks. Progress will be tracked in Allow macro annotation to transform companion · Issue #19676 · lampepfl/dotty · GitHub

2 Likes