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 ?