Morgan :)

Thanks Jake! There are some tricky corners here, for sure. Fortunately I think covering the AST part with a schema does not restrict our options, there are a bunch of...

Jake and I chatted about this a bit; the more I think about it the more I think JSON is a natural fit. Subtrees of JSON can reference external schemas...

> The current proposal says "All identifiers in code must be defined outside of the current [strongly connected component](https://en.wikipedia.org/wiki/Strongly_connected_component) (that is, the strongly connected component which triggered the current macro...

I chatted to Jake about this yesterday, and attempted to make progress today by digging into the analyzr's `DartObject` code and Johnni's example code. My conclusion is that we probably...

@munificent Coincidentally I shared (internally) last week a doc about evolving `dart_model`, I added you to the email thread :) tl;dr: I think macros already poses significant risk to further...

Note that we have limited ability to "disallow" things, because a macro annotation has no restrictions and anyway a macro can inspect a non-macro annotation; we can only find problems...

Agreed. I think we can leave enough space in the hostmacro protocol that this is the kind of improvement we can make later.

I think part of why this is hard is we just don't have good examples to point to. Most existing code generators generate implementation without adding API. One generator I...

`source_gen` will have to wait until `build` does an element2 release which will take a little while--working on it https://github.com/dart-lang/build/issues/3977 Analyzer `7.4.0` still fully supports element1, so when you say...

> Yes, there is a tiny loss of expressiveness in that you can't prevent a parameter being reassigned inside the body of a function. Who cares? I'd love to get...