Bob Nystrom

That's an excellent point. I [updated the proposal yesterday](https://github.com/dart-lang/language/commit/22ef7f2449da55af41803e7411eb10a61c8ca99c) to state that the expressions are eagerly evaluated. This more firmly convinces me that eager is the right answer.

> Is this feature still being pursued even if the metaprogramming does not end up needing it? I feel like this could still be a very usefull featue in any...

It's not being actively worked on right now. We've got our hands full with views, records, patterns, and some other work. :)

I'm still interested in the proposal (and think it would be helpful for macro authors to make a nicer API for generating code), but it hasn't risen to the top...

> The missing return case does seem more obnoxious to me though. In practice, I don't think this will be a huge pain point. This only comes in play when:...

Good catch, fixed!

We would probably want both `ref` and `out` parameters, like in C#. Otherwise, the definite assignment analysis doesn't work as well because it can't tell which parameters will be definitely...

We've talked recently about statement-level or expression-level metaprogramming through something like [inline functions](https://kotlinlang.org/docs/inline-functions.html) or [compile-time execution](https://ziglang.org/documentation/master/#comptime). I wonder if we could subsume this feature under that. If we had something...

> the macro receives its parameters basically _by name_. Macros receive the parameter expression as unevaluated syntax. You could write a `swap()` macro that does what you want, but the...

#4357 removes `augmented()` completely, so I have cut this Gordian knot. :)