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
    }

}

[idkq]

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.

Interesting. I like the structure a lot, but not so much #ToStringMaker() (hashtag working as annotation). Syntax would be better if #ToStringMaker() could be incorporated into the class definition.

[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.

[ghost]

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!

[ghost]

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?

[ghost]

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.

[ghost]

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

[TekExplorer]

You know, the biggest benefit macros provided was the live on-the-spot code gen

But the actual API was... Not great.

Is there any chance we could get just the instant gen and just leave the actual implementation and introspection to the ecosystem to refine on its own?

Also, could I get an enumeration of the exact reasons the attempt failed as-is? Just so I don't re-tread covered grounds.

Because sometimes I want to make a quick extension on a function type, multiple times, but not enough to want to pull out build_runner.

[insinfo]

Also, could I get an enumeration of the exact reasons the attempt failed as-is?

I would also really like to know this, because if the problem is just performance, this could be improved over the years, seeing as the Rust compilation has improved over the years, in addition to better software optimizations, there are also hardware improvements over time.

[insinfo]

I think it might be interesting if the dart SDK (compiler/analyzer) had an extension plugin API with hooks so that the community could develop a macro package that could be coupled to the SDK with fewer barriers than build_runner, in a more integrated way so that a package that depends on it doesn't force the package user to have to put build_runner as a dependency and have to run dart run build_runner build, that is, so that this becomes transparent to the package user, eliminating this barrier would be very good and it would work almost like the native macros of the dart SDK.

[davidmorgan]

Also, could I get an enumeration of the exact reasons the attempt failed as-is?

I would also really like to know this, because if the problem is just performance, this could be improved over the years, seeing as the Rust compilation has improved over the years, in addition to better software optimizations, there are also hardware improvements over time.

You can look through the closed issues tagged static-metaprogramming on the language repo, there were plenty of large open issues to choose from.

The biggest functional piece missing was the capability to pass configuration to macros, e.g. JsonSerializable(key: 'foo'). We had ideas for this but not much progress on an actual implementation--it's hard for a lot of reasons.

Macros would have run as you type in the IDE, it simply does not make sense to release a macros or macros-like feature and promise it will be faster later :)

[TekExplorer]

The biggest functional piece missing was the capability to pass configuration to macros, e.g. JsonSerializable(key: 'foo'). We had ideas for this but not much progress on an actual implementation--it's hard for a lot of reasons.

i feel like extension types could have been great for that.

also a lot of the issues are regarding api and analysis.

i dont think we even "had" the feature for long enough to even care about that yet.

I can easily imagine:

macro class MyMacro {
  // you could get the actual value, but this is more useful for emitting to straight to code. basically a Reviver'd version, by my understanding
  final Literal<String> key;
  // information, no coercion or anything
  final String info;
  // the type itself is useless, but as its a literal, it secretly retained the associated element, so we can still use it for type analysis
  // possibly has a `.identifier` getter
  final Literal<Type> supertype;
  // possibly used for non-const superpowers, if we want the revivable, but dont care to read the value directly in the macro.
  final Code</*ExpectedType*/> something;
}

Literal() is Code

seems simple enough, but i'm not deep enough in implementation code to actually say that i suppose.

[davidmorgan]

seems simple enough, but i'm not deep enough in implementation code to actually say that i suppose.

It's very hard.

• constant evaluation can't run before macros, because macros are part of constant evaluation; so macros can't see fully evaluated parameters
• if what the macros sees is some representation of the source code, this is something that has to be able to change as the language evolves
• full source code isn't necessarily available while compiling: dependencies can be provided as kernel or as analyzer summaries; so any source code representation has to be baked into the toolchain including at least these two intermediate formats

Codegen just fails if it asks for ASTs where they're not available, but that's not an option for a language feature.

Codegen just breaks when ASTs change :) also not an option for a language feature.

[ghost]

There's one key reason: complexity. It gives rise to a potentially infinite number of problems, each of which, in turn, ... etc.

[insinfo]

Macros would have run as you type in the IDE

This seems like a bad idea. To me, the IDE should ignore macros and only the compiler should analyze and process the macros and generate code when compiling the code. Making the IDE analyze and generate code when typing is absurdly expensive. The user experience doesn't need to be magical. See, when you use very dynamic things, you only know for sure the result when running or compiling, and that's not the end of the world. You don't need to have the best UX in the world to be very useful.

[TekExplorer]

Macros would have run as you type in the IDE

This seems like a bad idea. To me, the IDE should ignore macros and only the compiler should analyze and process the macros and generate code when compiling the code. Making the IDE analyze and generate code when typing is absurdly expensive. The user experience doesn't need to be magical. See, when you use very dynamic things, you only know for sure the result when running or compiling, and that's not the end of the world. You don't need to have the best UX in the world to be very useful.

That's a great way to completely shut down analyzer-level type safety.

How are you supposed to use a generated type otherwise?

[insinfo]

There is no miracle, there is always a compromise, there are always pros and cons in everything, it is not feasible to make the IDE analyze the entire project with each keystroke, that is madness, but having said that there is no loss of type safety once the compiler finds an error it will show it.

[TekExplorer]

There is no miracle, there is always a compromise, there are always pros and cons in everything, it is not feasible to make the IDE analyze the entire project with each keystroke, that is madness, but having said that there is no loss of type safety once the compiler finds an error it will show it.

And how is the ide meant to find an error for a type it doesn't yet know exists because it hasn't been macro-expanded?

If perhaps we reanalyzed after we pause typing, or when we ask for it (configurable? On-save? Oh hi build_runner watch) then that would at least make sense.

Hey, maybe we should go and abuse custom_lint quick-fixes as crappy macros! Heh.