Morgan :)

I meant, fit into how we want macro authors to actually interact with the data, via extension types. At the moment I'm happy with the tradeoffs around JSON + custom...

The plan is to have generated extension types that match the definitions in the JSON schema https://github.com/dart-lang/macros/blob/main/pkgs/dart_model/lib/src/dart_model.g.dart with whatever convenience methods we want to add on top of that.

Well ... whether it's exposed to users or not depends rather on whether you consider the capability to cast to `Map` as exposing the format ;) I do think macro...

The extension types expose exactly what's in the schema; we can add whatever code we want into the extension types, so we can add whatever convenience methods we want _next...

> We're not going to be running multiple client versions against the same service, they're all compiled against the same `dart:macros`, which is the one that works with the tools...

> > That's simply not true, however much we would like it to be true. We have already broken google3 and Flutter via the macro experiment as a result. >...

Also related: [#3728](https://github.com/dart-lang/language/issues/3728) for the move to use annotations for macro metadata.

Hi @pattobrien, configuration with yaml files is over at #3728, this issue is about introspection on macro annotations and other annotations ... sorry, I didn't really make that clear in...

Hi everyone :) @jakemac53 @scheglov this is my writeup of @johnniwinther's [exploratory work][1] for this issue after discussion with him. It's intended to kick off a round of discussion on...

It's always tempting to push complexity to a shared client library, but then instead of a schema that you know you can evolve safely, you have a hybrid of schema...