Bob Nystrom

This is all well-though-out and expressive. But I gotta say, it's a *lot* of complexity. That comment is about 1/3 of the length of the entire augmentations proposal. I don't...

Oh, this is a really good comment. I forgot about the restriction on not having other generative constructors if you have a primary constructor. Assuming we're building on proposal 1...

> But [being complete] is not implied by having instance variables with initializer expressions referring to primary constructor parameters. This part is pretty spooky to me. It requires adding another...

> And we need to do that no matter what. > _And if we want to have the same initialization order for non-primary initializing constructors, we need to do **something**...

GitHub really needs a 🤯 reaction for your follow-up comment. That all sounds right to me.

Pattern matching makes the most sense when you're matching on is an immutable blob of data. In fact, Dart goes way out of its way to manufacture those semantics even...

There's always going to be an impedance mismatch when porting code from one paradigm to another. While I do think it's important for Dart to have good support for programming...

> More generally, and out of correctness, it seems inconsistent that `FutureOr f() {}` is legal, a function body that falls off the edge without returning a value, but `FutureOr...

No news. We've been very focused on non-nullable types and extension methods, so haven't had time for many other small-scale language changes.

I really like this idea. As @nex3 suggests, I'd probably want to stick to simple identifiers and *maybe* identifiers wrapped in prefix expressions (which we allow for patterns). Going beyond...