More naming in namer for annotations


I have been informally briefed by @olafurpg on some tentative plans for production ready macros in scala and I give my thumbs up to everything he’s said: scala.meta will be for tooling (powered by the semanticdb and maybe other compiler plugins), whitebox macros / annotation macros will be retired, and a scala.meta-like API will be used for the new blackbox macros. Individual macros may or may not require a dual IntelliJ plugin (it’s not too hard anyway, I’ve done it). Great stuff! Sounds eminently doable and of huge value to the stability of the language.

Sadly it does make the GSoC implementation of the optimised data types rather redundant… but that’s the price of R&D.

However, the community has come to rely on many macro annotations and it is not possible to survive if we throw away the only mechanism for doing so. In particular, I am unable to rewrite many of my own macro annotations because post-namer, pre-typer compiler plugins do not have a reliable mechanism for identifying the correct annotation! The FQNs have not been resolved so the plugin must work only on raw source code name, ignoring language semantics such is imports and aliases.

In addition, I often require the parameters to my annotations to be resolved to FQNs. Consider for example the “deriving” macro that takes a list of companions of typeclasses to derive… we need access to the FQNs of these typeclasses, not just the raw source names.

The compiler plugin API needs additional mechanisms (some outlined here) that would make it possible for the community to migrate their macro annotations to compiler plugins.

I can’t find Dmitry’s handle… could somebody please ping him?

Pre-Pre-SIP: Macros


moving to Annotation macros