Sorry if my question looks provocative, too general or wrongly-placed, but in my own defense I can say that after ignoring Scala macro for 7+ years, I’ve finally managed to write my first working, usable and useful (!) macro in Scala 3 and I need to say I’m completely blown away by macros and thrilled to even think how many things we can achieve with them and where it will bring Scala ecosystem as a whole.
Given all that I cannot hold my curiosity about future of macro subsystem and wanted to ask people who work closely on it - what are the next steps and where it goes? Is complete now? Are there any known big limitations that you think we can lift? Or do you think we have to wait until macro-libraries start to bloom which should show the direction of work?
I know there are macro annotations coming in 3.3.0 and that’s awesome, but is there anything beyond that?
Again, I know how hard it is to talk about estimates and roadmap in such an experimental land, but any general overview and/or sneak peek would highly appreciated.
And thanks for all your hard work, I think Scala has now bright and solid future (that’s not macro only).
The way it works right now is that the first vote is sufficient but not necessary to merge something in the compiler as experimental, but this isn’t the right thread to discuss this.
Some clarification about the process. The compiler team and the SIP Committee are different bodies:
When the SIP Committee approves a design proposal, it signals to the community and tool implementers (e.g. scalafmt, scalameta, IntelliJ, etc.) that the Committee is in favor of having that proposal in the language. An experimental implementation in the compiler is welcome (from the compiler team, or an external contributor).
After the change has been available as an experimental feature for enough time, the Committee needs to vote to make it officially part of the language (ie, non-experimental).
Independently of that, the compiler team is free to make experiments directly in the compiler, but they can’t make non-experimental changes (ie, any changes they make stay experimental until they are approved by the SIP Committee).
This way, the compiler team can already start working on the implementation of a proposal without having to wait for that proposal to be approved by the Committee, and without impacting the users who only use stable language features.
Maybe this should be made clearer in the SIP specification, as I was also under the impression a SIP approval was necessary to merge something into main
(Technically the specification is correct, as it only says “accept for implementation” => “implementation starts”, and does not say anything about what happens when the first statement is false, but it would still be a good thing to clarify)
I agree it would be good to make an explicit note in the process document. We had a long discussion exactly about this some time ago, and we agreed on what Julien said (I was the one to initially advocate for gating merges by a commitee vote, but I was ultimately convinced it’s better not to)