Static Metaprogramming

[jakemac53]

Metaprogramming refers to code that operates on other code as if it were data. It can take code in as parameters, reflect over it, inspect it, create it, modify it, and return it. Static metaprogramming means doing that work at compile-time, and typically modifying or adding to the program based on that work.

Today it is possible to do static metaprogramming completely outside of the language - using packages such as build_runner to generate code and using the analyzer apis for introspection. These separate tools however are not well integrated into the compilers or tools, and it adds a lot of complexity where this is done. It also tends to be slower than an integrated solution because it can't share any work with the compiler.

Sample Use Case - Data Classes

The most requested open language issue is to add data classes. A data class is essentially a regular Dart class that comes with an automatically provided constructor and implementations of ==, hashCode, and copyWith() (called copy() in Kotlin) methods based on the fields the user declares in the class.

The reason this is a language feature request is because there’s no way for a Dart library or framework to add data classes as a reusable mechanism. Again, this is because there isn’t any easily available abstraction that lets a Dart user express “given this set of fields, add these methods to the class”. The copyWith() method is particularly challenging because it’s not just the body
of that method that depends on the surrounding class’s fields. The parameter list itself does too.

We could add data classes to the language, but that only satisfies users who want a nice syntax for that specific set of policies. What happens when users instead want a nice notation for classes that are deeply immutable, dependency-injected, observable, or differentiable? Sufficiently powerful static metaprogramming could let users define these policies in reusable abstractions and keep the slower-moving Dart language out of the fast-moving methodology business.

Design

See this intro doc for the general design direction we are exploring right now.

Update January 2025

We have an unfortunate update on macros/metaprogramming. We have invested significant time and resources to prototype macros over the past couple years. Unfortunately, each time we solved a major technical hurdle, we saw new ones pop up. At this point, we are not seeing macros converging anytime soon toward a feature we are comfortable shipping, with the quality and developer-time performance we want.

After considering the opportunity cost — in particular, the features we could be shipping to the community instead — we’ve made the difficult decision to stop our work on macros.

For additional details, please see the blog post:
https://medium.com/dartlang/an-update-on-dart-macros-data-serialization-06d3037d4f12

[rrousselGit]

Would static function composition be in the scope of this feature?

At the moment, higher-order functions in Dart are fairly limited since they require knowing the full prototype of the decorated function.

An example would be a debounce utility:

void Function() debouce(Duration duration, void Function() decorated) {
  Timer? timer;
  return () {
    timer?.cancel();
    timer = Timer(duration, () => decorated());
  };
}

which allows us to, instead of:

class Example {
  void doSomething() {

  }
}

write:

class Example {
  final doSomething = debounce(Duration(seconds: 1), () {
  
   });
}

but that comes with a few drawbacks:

• obvious readability decrease
• our debounce utility is not very reusable. It works only on void Function(), but we'd like it to work for all functions.

With static meta-programming, our debounce could inject code in the class at compilation, such that we could write:

class Example {
  @Debounce(Duration(seconds: 1))
  void doSomething() {
    print('doSomething');
  }
  
  @Debounce(Duration(seconds: 1))
  void doSomethingElse(int value, {String named}) {
    print('doSomethingElse $value named: $named');
  }
}

[jakemac53]

There is a delicate balance re: static function composition, but there are certainly many useful things that could be done with it. I think ultimately it is something we would like to support as long as we can make it obvious enough that this wrapping is happening.

The specific balance would be around user confusion - we have a guiding principle that we don't want to allow overwriting of code in order to ensure that programs keep their original meaning. There are a lot of useful things you could do by simply wrapping a function in some other function (some additional ones might include uniform exception handling, analytics reporting, argument validation, etc). Most of these things would not change the meaning really of the original function, but the code is being "changed" in some sense by being wrapped.

Ultimately my sense is this is something we should try to support though. I think the usefulness probably outweighs the potential for doing weird things.

[mateusfccp]

I like Lisp approach (in my opinion, the utmost language when it comes to meta-programming). Instead of defining a @Debounce or something alike, we would define new syntax that would simply expand to a regular method at compile-time. I don't know, however, how much complex is to make something like this considering Dart syntax.

[lrhn]

For something like debounce, a more aspect-like approach seems preferable. Say, if you could declaratively wrap a function body with some template code:

class Example {
  void doSomething() with debounce(Duration(seconds: 1)) {
    print('doSomething');
  }
  
  void doSomethingElse(int value, {String named}) with debounce(Duration(seconds: 1)) {
    print('doSomethingElse $value named: $named');
  }
}

template debounce<R>(Duration duration) on R Function {
  template final Stopwatch? sw;
  template late R result;
  if (sw != null && sw.elapsed < duration) {
    return result;
  } else {
    (sw ??= Stopwatch()..start()).reset();
    return result = super;
  }
}

This defines a "function template" (really, a kind of function mixin) which can be applied to other functions.
It cannot change the signature of the function, but it can access arguments (by forwarding them as with templateName(arg)), and it can do things before and after the original body is run.
The template variables are per-template instantiation variables (just as we could declare static variables inside normal functions).

(Maybe we just need AspectD for Dart.)

[rrousselGit]

It cannot change the signature of the function, but it can access arguments

But an important part of function composition is also the ability to inject parameters and ask for more parameters.

For example, a good candidate is functional stateless-widgets, to add a key parameter to the prototype and inject a context parameter.
This means the user would define:

@statelessWidget
Widget example(BuildContext context, {required String name}) {
  return Text(name);
}

and the resulting prototype after composition would be:

Widget Function({Key? key, required String name})

where the final code would be:

class _Example extends StatelessWidget {
  Example({Key? key, required String name}): super(key: key);

  final String name;

  @override
  Widget build(BuildContext) => originalExampleFunction(context, name: name);
}

Widget example({Key? key, required String name}) {
  return _Example(key: key, name: name);
}

[jakemac53]

I definitely agree we don't want to allow for changing the signature of the function from what was written. I don't think that is prohibitive though as long as you are allowed to generate a new function/method next to the existing one with the signature you want. The original function might be private in that case.

[rrousselGit]

I don't think that is prohibitive though as long as you are allowed to generate a new function/method next to the existing one with the signature you want

That's what functional_widget does, but the consequence is that the developer experience is pretty bad.

A major issue is that it breaks the "go to definition" functionality because instead of being redirected to their function, users are redirected to the generated code

It also causes a lot of confusion around naming. Because it's common to want to have control on whether the generated class/function is public or private, but the original function to always be private.

By modifying the prototype instead, this gives more control to users over the name of the generated functions.

[jakemac53]

Allowing the signature to be modified has a lot of disadvantages as well. I think its probably worse to see a function which is written to have a totally different signature than it actually has, than to be navigated to a generated function (which you can then follow through to the real one). You can potentially blackbox those functions in the debugger as well so it skips right to the real one if you are stepping through.

[bouraine]

I suppose this will allow generating fromJson and toJson methods at compile time for Json serialization ?

[mateusfccp]

@bouraine

I suppose this will allow generating fromJson and toJson methods at compile time for Json serialization ?

Yes.

[jakemac53]

@tatumizer This issue is just for the general problem of static metaprogramming. What you describe would be one possible solution to it, although we are trying to avoid exposing a full AST api because that can make it hard to evolve the language in the future. See https://github.com/dart-lang/language/blob/master/working/static%20metaprogramming/intro.md for an intro into the general design direction we are thinking of here which I think is not necessarily so far off from what you describe (although the mechanics are different).

[idkq]

Great intro & docs.

Hopefully we'll stay (far far) away from annotations to develop/work with static meta programming?!

[jakemac53]

so it looks like copyWith is seen as a crown jewel of the upcoming facility

The main reason we use this as an example is its well understood by many people, and it is also actually particularly demanding in terms of features to actually implement due to the public api itself needing to be generated :).

The language needs some mechanism of dealing with default values, which has been a showstopper in dart from day one.

Can you elaborate? Default values for parameters are getting some important upgrades in null safe dart (at least the major loophole of being able to override them accidentally by passing null explicitly is closed).

[rrousselGit]

Can you elaborate? Default values for parameters are getting some important upgrades in null safe dart (at least the major loophole of being able to override them accidentally by passing null explicitly is closed).

I believe the issue is that we cannot easily differentiate between copyWith(name: null) and copyWith() where the former should assign null to name and the latter just do nothing

freezed supports this, but only because it relies on factory constructors and interface to hide the internals of copyWith (that is in fact a copyWith({Object? name = _internalDefault}))

[jakemac53]

I believe the issue is that we cannot easily differentiate between copyWith(name: null) and copyWith() where the former should assign null to name and the latter just do nothing

Right, this is what I was describing which null safety actually does fix at least partially. You can make the parameter non-nullable (with a default), and then null can no longer be passed at all. Wrapping functions are required to copy the default value, basically it forces you to explicitly handle this does cause some extra boilerplate but is safe.

For nullable parameters you still can't differentiate (at least in the function wrapping case, if they don't provide a default as well)

[idkq]

Metaprogramming is a broad topic. How to rationalize? We should start with what gives the best bang for buck (based on use cases).

Draft topics for meta programming 'output' code:

1. Methods
2. Classes (shell)
3. Class members
4. Types
5. Enums
6. Statements (?)
7. Mixins (?)
8. Generics (?)

Also on output code:

Be able to visualize in some way the code generated into your program, at development time
(https://github.com/dart-lang/language/blob/master/working/static%20metaprogramming/intro.md#usability)

Would be great if this could work without saving the file, a IDE-like syntax (hidden) code running continuously if syntax is valid. I refuse to use build_runner's watch

[porfirioribeiro]

Metaprograming opens doors to many nice features
For the data class thing, this is something i miss from Kotlin.
When i used Java we used @Data / @Value from Lombok that was some sort of generator, i guess having something like this would be enough for the data class's

Other language that does a great job at implementing macros is Haxe you can use Haxe language to define macros

I guess there are many challenges to implement this.

[ykmnkmi]

can we extend classes with analyzer plugin?
can we use external and patch like patches in sdk libraries for extending classes?
plugins for CFE?

[escamoteur]

I'm not sure if I like the idea having this added to Dart because the beauty of Dart is its simplicity. The fact that it isn't as concise as other languages it in reality an advantage because it makes Dart code really easy to read and to reason about.
I fear meta programming will kill this. How will a goto-definition in an IDE work with it? How discoverable and maintainable is such code?

[jodinathan]

I'm not sure if I like the idea having this added to Dart because the beauty of Dart is its simplicity. The fact that it isn't as concise as other languages it in reality an advantage because it makes Dart code really easy to read and to reason about.
I fear meta programming will kill this. How will a goto-definition in an IDE work with it? How discoverable and maintainable is such code?

I agree with this.
I like the idea of meta programming as long as it doesn't remove how readable and maintainable a Dart code is.

[idkq]

@escamoteur Writing less code does not make it more complicated necessarily. It can, I agree, if someone does not fully understand the new syntax. But the trade-off is obvious: time & the number of lines saved vs the need for someone to learn a few capabilities.

Generated code is normal simple code. I just suggested real-time code generation instead of running the builder every time or watching it to save. That way you get real time goto. But if you are using notepad then of course you need to run a process.

[leafpetersen]

I'm not sure if I like the idea having this added to Dart because the beauty of Dart is its simplicity. The fact that it isn't as concise as other languages it in reality an advantage because it makes Dart code really easy to read and to reason about.
I fear meta programming will kill this. How will a goto-definition in an IDE work with it? How discoverable and maintainable is such code?

Just to be 100% clear, we are intensely focused on these exact questions. We will not ship something which does not integrate well with all of our tools and workflows. You should be able to read code and understand it, go to definition, step through the code in the debugger, get good error messages, get clear and comprehensible stack traces, etc.

[jodinathan]

@escamoteur Writing less code does not make it more complicated necessarily. It can, I agree, if someone does not fully understand the new syntax. But the trade-off is obvious: time & the number of lines saved vs the need for someone to learn a few capabilities.

Generated code is normal simple code. I just suggested real-time code generation instead of running the builder every time or watching it to save. That way you get real time goto. But if you are using notepad then of course you need to run a process.

In my honest opinion: things must be obvious, not magical.
Every time I have to read or develop in PHP, JS or C with preprocessors etc... I just hate it.
Too many magical stuff that you just can't read or debug easily.
Dart is the opposite of that without being boring as hell as Java.
In fact, there was a time that some Dart packages used to implement the noSuchMethod to create magical methods. Gee, what a pain.
Meta programming could be the next Dart transformers if it takes the glittering magical road.

Just to be 100% clear, we are intensely focused on these exact questions. We will not ship something which does not integrate well with all of our tools and workflows. You should be able to read code and understand it, go to definition, step through the code in the debugger, get good error messages, get clear and comprehensible stack traces, etc.

^ this

[esDotDev]

I'm not sure if I like the idea having this added to Dart because the beauty of Dart is its simplicity.

But there is nothing beautiful about writing data classes or running complicated and and slow code-generation tools.

I'm hoping this can lead to more simplicity not less. Vast mounds of code will be removed from our visible classes. StatefulWidget can maybe just go away? (compiler can run the split macro before it builds?). Things can be auto-disposed. Seems like this could hit a lot of pain points, not just data classes and serialization..

[safasofuoglu]

Since dart currently offers code generation for similar jobs-to-be-done, I'd suggest evaluating potential concerns with that consideration:

• Metaprogramming is not simple/obvious - can it be made at least as simple/obvious as codegen through tooling?
• Metaprogramming will be abused - Is there a reason to think it will be abused more than codegen? (potentially, if it provides better ergonomics)

On the other hand, besides being an upgrade from codegen for developers, metaprogramming could provide healthier means for language evolution beyond getting data classes done. Quoting Bryan Cantrill:

Another advantage of macros: they are so flexible and powerful that they allow for effective experimentation. For example, the propagation operator that I love so much actually started life as a try! macro; that this macro was being used ubiquitously (and successfully) allowed a language-based solution to be considered. Languages can be (and have been!) ruined by too much experimentation happening in the language rather than in how it’s used; through its rich macros, it seems that Rust can enable the core of the language to remain smaller — and to make sure that when it expands, it is for the right reasons and in the right way.
http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/

PS @jakemac53 the observable link leads to a private google doc.

[insinfo]

this would be fantastic if it allowed, the longed-for serialization for JSON natively without the need for manual code generation or reflection in time of execution

Today practically all applications depend on serialization for JSON, a modern language like dart should already have a form of native serialization in the language, being obliged to use manual codegen or typing serialization manually is something very unpleasant

[felixblaschke]

My approach on a macro mechanism. Basically tagging a certain scope with a macro annotation, that refers to one or multiple classes to 1:1 replace the code virtually... like a projection. It's very easy to understand and QOL can be extended by providing utility classes.

#ToStringMaker() // '#' indicates macro and will rewrite all code in next scope
class Person {
    String name;
    int age;
}

// [REWRITTEN CODE] => displayed readonly in IDE
// class Person {
//    String name;
//    int age;
//
//    toString() => 'Person(vorname:$name, age:$age)'
// }

class ToStringMaker extends Macro {

    // fields and constructor can optionally obtain parameters

    @override
    String generate(String code, MacroContext context) { // MacroContext provides access to other Dart files in project and other introspection features
        var writer = DartClassWriter(code); // DartClassWriter knows the structure of Dart code

        writer.add('String toString() => \'${writer.className}(${writer.fields.map(field => '${field.name}:\${field.name}').join(', ')})\'');

        return writer.code; // substitute code for referenced scope
    }

}

[jodinathan]

What would be the size impact of a minimal subset of mirrors (allowing to create data classes & serialization) ?

What would be the size impact on a class marked as introspectable (allowing tree shakes on others) ?

The idea of a “minimal subset of mirrors” is vague and unlikely to guarantee a small bundle size.

Even with an introspectable-only approach, if devs start marking everything as introspectable (which will happen), we’re back to square one.

IMO we need the Dart team to deliver smaller Flutter Web bundles–not the other way around. Only then can we drop other platforms and focus only on Flutter.

[cedvdb]

if devs start marking everything as introspectable (which will happen), we’re back to square one.

Unless the claim is that the flutter team, dart team and engine team would mark every class as introspectable, I don't see how we end up anywhere close to square one.

I believe your real claim is that packages authors will use it willy nilly. There is no reason to assume most devs would use that on their flutter widgets, so that leaves "abuse" to models and other classes. I'm sceptic the size impact would be meaningful, but it could be.

Look I'm with you, build_runner is probably going to be the better solution once things are ironed out but I refuse the conjectures made here. I'll just agree to disagree at this point, since this is only what ifs.

[davidmorgan]

No need to agree or disagree on these points--we are aware of all the issues and will be working towards the best solution we can find, whatever it turns out to be :)

[esDotDev]

I believe your real claim is that packages authors will use it willy nilly. There is no reason to assume most devs would use that on their flutter widgets, so that leaves "abuse" to models and other classes. I'm sceptic the size impact would be meaningful, but it could be.

Agreed, it's a fairly nonsensical claim. Developers would only need to mark as introspectable things they need to write to disk or send across the wire, this is typically <1% of the classes in your codebase from my 20+ yrs experience writing apps.

[TekExplorer]

I think that instead of mirrors, it makes more sense to just make types - and the language itself - more powerful.

• type patterns Type patterns #4215
• named generics (multiple different issues)
  • default generic that isnt the bound Type parameters with default value for classes #4087
  • required generics
• static interfaces Abstract static methods #356 Static extension methods #723 More capable Type objects #4200
• union types Unions as parameters #3608 (and related)
  • intersection types Multiple upper bounds #2709
• mixin composition Mixin composition #540 (i consider this straight up broken. i am genuinely amazed that mixins were produced but couldnt be composed)
• traits/interface injection Rust traits in Dart #3024
  • could be for extension types only
• more const to help with patterns and annotations Potentially constant statements and bodies. #4261
  • const closures Constant function literals #1048
  • const accessors
• static type operations
  • record type operations
    • function argument list as a record type
    • varargs?
    • lets us do things like remove an argument and pass along, or infinitely wide extensions (ie, X1, X2... XN just becomes X) for things like record.wait and type arguments etc.
• implicit constructors
• even more, but i'll stop here.
  • note: i have not pulled all related issues for each topic.

There's really so many features that would make mirrors and introspection so much less necessary, and improve the language far more. in addition, this very issue would be greatly enriched as well, since interfaces still need implementation, and boilerplate handled.

hell, a combination of some of these features might even allow for a rust-like Into<T> implementation of unions

I think that the macros hype has us too focused on metaprogramming - and dont get me wrong, we need it, and build_runner should absolutely be improved - but i dont think it should be our main solution to everything when most of the time all we have are workarounds.

in fact, some of those issues can be considered metaprogramming in a sense too.

[bsutton]

Agreed, it's a fairly nonsensical claim.

Pub.dev and the compiler could also be augmented to warn if a package used introspection.

I maintain 20+ packages on pub.dev and I can't think of a valid reason to use introspection in any of them.

In 20+ year of java I've only used introspection a hand full of times but when you need it, you need it.

[tatumizer]

I wonder why every time the mirrors get mentioned, the discussion diverges into tree-shaking, memory footprint etc, which is totally irrelevant.
I'm suggesting to use mirrors only in build time.
That is, the program gets fully compiled with mirrors enabled, but instead of running main, it invokes build_main method.
And this method controls everything
E.g., to generate serializers, it examines all classes having an annotation @jsonSerializable, and through mirrors retrieves all meta-information about each class. Then it generates the code for the serializer. It's not necessary to place this code into the class itself - it can go into JsonSerializer. E.g. in C#

var weatherForecast = new WeatherForecast
     {
         Date = DateTime.Parse("2019-08-01"),
         TemperatureCelsius = 25,
         Summary = "Hot"
     };
     string jsonString = JsonSerializer.Serialize(weatherForecast); // the code resides in JsonSerializer, not in WeatherForecast!

But what if you want a different serialization format, and you cannot annotate somebody else's classes?
You can hardcode a list of classes you want to be serializable, or, in general: 1) retrieve mirrors for the classes matching a certain criterion 2) generate serialization code, as above.
With mirrors, you can do things that are impossible to do otherwise.
In runtime, all mirrors disappear.
What not to like here?

[TekExplorer]

How would you even output code?

[tatumizer]

How would you even output code?

By writing it to disk!
(Was it a trick question? :-)

[TekExplorer]

How would you even output code?

By writing it to disk!
(Was it a trick question? :-)

This just sounds like the current setup but we do things with mirrors instead of the analyzer

[tatumizer]

You can do 1000x more with the mirrors than with AST. And you can learn how to do it very quickly, so code generation becomes accessible to everyone. I don't know what the problem with build runner is, but I used to generate code in java using reflection, on a project of a huge size (hundreds of thousands of lines), and it worked very fast. The code you want to generate is not necessarily dart code - in my case, the target was java AND javascript.

The main difference is that the generator via mirrors is NOT annotation-driven. Generator is a normal procedural program.

[TekExplorer]

You can do 1000x more with the mirrors than with AST. And you can learn how to do it very quickly, so code generation becomes accessible to everyone. I don't know what the problem with build runner is, but I used to generate code in java using reflection, on a project of a huge size (hundreds of thousands of lines), and it worked very fast. The code you want to generate is not necessarily dart code - in my case, the target was java AND javascript.

The main difference is that the generator via mirrors is NOT annotation-driven. Generator is a normal procedural program.

How would that even work? I have to ask because I don't think mirrors work on incomplete code, which we are trying to compete.

[tatumizer]

We will have to mark an incomplete code as incomplete. C# uses the word partial for this. Dart can do something similar - e.g. via an annotation. The "incompleteness" will be reflected in mirrors.
The generator will be able to execute the methods from the code under inspection, examine the code (every mirror provides the source as String), etc. The mirrors were fantastic. They were much more powerful than java's reflection. I don't remember the details, but I was impressed.
Sure, some work has to be done to design this feature, but it's worth it IMO.

[davidmorgan]

You can do 1000x more with the mirrors than with AST. And you can learn how to do it very quickly, so code generation becomes accessible to everyone. I don't know what the problem with build runner is, but I used to generate code in java using reflection, on a project of a huge size (hundreds of thousands of lines), and it worked very fast. The code you want to generate is not necessarily dart code - in my case, the target was java AND javascript.

The main difference is that the generator via mirrors is NOT annotation-driven. Generator is a normal procedural program.

I do know what the problem with build_runner is :) and I'm fixing it. So, when thinking about what comes next, it is probably helpful to assume that build_runner is fast. It will certainly be faster than using mirrors, because mirrors requires compile+run whereas generators only need analysis.

[tatumizer]

JIT compilation is fast, even with the mirrors enabled.
build_runner is slow.
Maybe eventually it will become as fast, but won't become as powerful. Or as accessible.

[TekExplorer]

did we ever consider a declarative mechanism for macros?
something like:

macro Data on T {
  `T` copyWith({
        for (final field in fields)
          `field.type.nullable` `field.name` = this.`field.name`, // non-const defaults
      }) => `primaryConstructor.autoCall(fields)`; // strawman
}
// basically, normal code, but anything wrapped in `` is dependent on introspection

I know that a lot of code gen isnt so simple, but i would say that enough are.
Since it would declare its own added methods, tools can just ignore the body and grab only the interface.
Plus, we get help from the analyzer here too, since the type of those expressions would resolve into the meta types you'd expect, like how T is Type code and field.type.nullable is also Type code wheras field.name is a symbol/identifier

It just seems a bit strange to me why we seem so hard-set on raw string code gen

[Ali1Ammar]

@TekExplorer look very promising , is there any other language support somethings like this?

[stan-at-work]

did we ever consider a declarative mechanism for macros?
something like:

macro Data on T {
  `T` copyWith({
        for (final field in fields)
          `field.type.nullable` `field.name` = this.`field.name`, // non-const defaults
      }) => `primaryConstructor.autoCall(fields)`; // strawman
}
// basically, normal code, but anything wrapped in `` is dependent on introspection

I know that a lot of code gen isnt so simple, but i would say that enough are.
Since it would declare its own added methods, tools can just ignore the body and grab only the interface.
Plus, we get help from the analyzer here too, since the type of those expressions would resolve into the meta types you'd expect, like how T is Type code and field.type.nullable is also Type code wheras field.name is a symbol/identifier

It just seems a bit strange to me why we seem so hard-set on raw string code gen

This looks really good

[TekExplorer]

@TekExplorer look very promising , is there any other language support somethings like this?

off the top of my head; rust's macro_rules!

[tatumizer]

rust_rules are very complicated.
It's one of the (many) examples where rust went overboard, fueled by the initial enthusiasm.
What you are proposing here is rather a kind of templating syntax. This was discussed earlier, and IMHO, there's nothing better than the current approach (populating the array of tokens and then concatenating them by a join()).

[stan-at-work]

Why is very complicated a bad thing?

[tatumizer]

Oh, don't get me started on this.
First, read this:
https://www.infoworld.com/article/2270714/complexity-is-killing-software-developers.html

I've been a developer for 40 years (before retiring). And if I learned one thing over that time, it's that complexity kills.
In retrospect, it's obvious, but you have to really feel it. When I see a complicated design (or myself come up with something complicated), I know: it won't work. (I knew that metaprogramming, as it was designed, won't work).
The concepts have to be crisp, then the programming will be a joyous experience. Complexity, on the other hand, kills not only the project - it kills you.

[lucavenir]

is there any other language support somethings like this

I hope I'm not adding noise in here. But since someone asked...
In Elixir, we do get this syntax exactly, with quote and unquote keywords. Elixir uses tuples (function name, metadata and arguments) to represent the AST, but the end result is fairly readable e.g.

defmodule LoggerExample do
  for {i, level} <- %{1 => :err, 2 => :warn, 3 => :info} do
    def log_level(unquote(i)), do: unquote(level)
  end
end

The above is (AFAIK!) unfeasible in Dart: for example, Elixir is dynamically typed (as of now 👀), Dart's not; and that's just the tip of the iceberg (analysis, macro debugging / exploration, type-safety, dartVM, hot reload, etc.).

Indeed the team abandoned macros for a reason, and that is, behind these "simple" examples, there's A LOT of complexity.

[tatumizer]

If you are looking for a prior art applicable to dart (more or less), Julia has it:

module AnotherModule
    export @show_value_user_and_module

    orange = "bitter"

    macro show_value_user_and_module(variable)
        quote
            println("The ", $(string(variable)), " you passed is ", $(esc(variable)),
                " and the one from the module is ", $variable)
        end
    end
end

using .AnotherModule

@show_value_user_and_module orange

 // printout: 
 The orange you passed is sweet and the one from the module is bitter

Indeed the team abandoned macros for a reason, and that is, behind these "simple" examples, there's A LOT of complexity.

I haven't seen any design docs for build_runner, but I won't be surprised if the thing turns out to be as complicated (if not more) as the abandoned metaprogramming 😄

[davidmorgan]

JIT compilation is fast, even with the mirrors enabled. build_runner is slow. Maybe eventually it will become as fast, but won't become as powerful. Or as accessible.

Challenge accepted ;)

[mateusfccp]

did we ever consider a declarative mechanism for macros?
something like:

macro Data on T {
  `T` copyWith({
        for (final field in fields)
          `field.type.nullable` `field.name` = this.`field.name`, // non-const defaults
      }) => `primaryConstructor.autoCall(fields)`; // strawman
}
// basically, normal code, but anything wrapped in `` is dependent on introspection

I know that a lot of code gen isnt so simple, but i would say that enough are.
Since it would declare its own added methods, tools can just ignore the body and grab only the interface.
Plus, we get help from the analyzer here too, since the type of those expressions would resolve into the meta types you'd expect, like how T is Type code and field.type.nullable is also Type code wheras field.name is a symbol/identifier

It just seems a bit strange to me why we seem so hard-set on raw string code gen

This is basically what was proposed in #1989, although the straw man syntax was very different. And yes, there are many languages that use this approach, notably famous is Lisp, where quoting ' will prevent the expression from evaluating.

[lucavenir]

@davidmorgan In addition to this list, I'd like to add this bug to the pile.

Again, I'm sure addressing build_runner issues will uncover a lot of tech debt

[davidmorgan]

Thanks @lucavenir, I've marked it as a sub-issue of dart-lang/build#3806