Morgan :)

Thanks Lasse, thanks Jake. I am starting to think we will need to pull considerable metadata related to macros out of the dart files and into pubspecs. If Dart only...

Thanks. Yes, "macro import" would achieve the same separation of deps, and if it's the only way to get the separation, I'll take it ;) But then there is extra...

Thanks Jake. Re: "only relevant for something like bazel"--I can imagine macros declaring they will play nice to be useful for the analyzer+CFE, too. But all that we can build...

`static import` sounds like a correct solution ... I have not checked rigorously ;) ... but I do not like the UX implications for macros, or the language generally. `static...

Unfortunately, conflating imports for dartdoc with imports needed for the compile would severely threaten the performance, and even the _feasability_, of the Dart compile. By their very nature dartdoc "imports"...

Thanks Jake ... taking a closer look at "macro library" is instructive, I now think it is unfortunately _simpler_ than what we need. To see this, consider two nested macros:...

I think reflected imports is different to what I meant--but it's another good example of a case where there is a new type of dependency being introduced that build systems...

Thanks for the detailed reply Jake :) makes sense. > * **Subtyping**: If the user tries to pass a subtype of the type you accept, it _might_ be serializable (if...

> > BTW, I'm not saying it's a _good_ idea, but "macro that serializes macro args" is a pretty well defined use case for a first macro to publish /...

We might want that :) my guess is that we will have to expose enough of the serialization internals that it's possible to write a macro to assist with a...