This doc was updated 3 weeks ago?

https://github.com/dart-lang/language/blob/main/working/macr...

It was really stuck at "in progress" for a looong time, and it's still in the working set, so it means that's going to take yet another 2-3 Dart releases and a few more to stabilize for production.

> They're just codegen you can't see

Yes, and that's exactly how it should have been in the first place. No need to run buggy services, no need to constantly juggle newly generated files.

do you understand that things that you can't see still need to be juggled? the problems don't magically go away just because you can't see the artifacts. what happens is you lose complete control over how they're juggled and you retain as much control as the compiler owner deigns to give you (see generic in Go). please see all the pain of working templates in C++.

I do, I work with Rust templates and worked with C++ templates. Obviously, people aren't asking for such a granular level of metaprogramming.

> Obviously, people aren't asking for such a granular level of metaprogramming.

that `Obviously` is doing a lot of work there but more so i'm saying going from codegen facilities to static metaprogramming is a step in the wrong direction if the static metaprogramming is at the cost of the codegen.

[ I work on Dart ]

We're still working on this, and you can find updates in the language repo. One reason we're taking extra time here is that macros / static metaprogramming can blow up compile times and hot reload.

that's fine - i'm not complaining i'm waiting patiently. keep going!

We're actively working on static metaprogramming. It got slowed down during the lead-up to 3.0 because it was sort of all-hands-on-deck to get that set of features out and fully migrate stuff to null safety. Now that that's done, we're picking it back up.

It's a particularly hard feature to work on because it touches everything. Some of the kinds of stuff you run into are like:

* How do IDEs handle go-to-definition when the thing you're navigating to is generated through metaprogramming?

* What is the API we expose to macros and how does that API evolve when the language changes?

* If a macro adds a method to a class that shadows a top-level identifier, how does that interact with other method bodies in that class that might be referring to that identifier?

* What happens to the user experience when a macro takes a really long time to run? Can users tell which macros are running slowly? How?

* What happens when a macro throws an exception or otherwise fails?

* How does hot reload work with macros? How does macro performance affect hot reload time?

* What is the syntax for invoking a macro? What kinds of arguments can you pass to macros? Are they passed as values, raw syntax, meta-values? If they are passed as values, when are those values evaluated and in what context?

* Are macros expressive enough for the use cases we have? Are they too powerful? What kinds of things should you be able to do with macros? What kinds of things should you not be able to do?

* How does a user understand code that may be relying heavily on macros?

* What is the user experience for authoring a macro? What developer tools do we give you? What is it like maintaining a package that exposes publicly usable macros? When the language changes, what do macro package authors have to do to keep their package working?

Getting any of these answers wrong can really harm the whole user experience of the language, so it's just a big challenging ball of work with lots of stakeholders. We're making good progress and I'm really excited by everything Jake, Johnni, and Konstantin are doing, but it's definitely not something we want to rush.