Bob Nystrom

I got most of the way through augmentations, but it looks like the analyzer AST API isn't fully there yet. I'm missing: * `FunctionDeclarationImpl` has an `augmentKeyword` field, but `FunctionDeclaration`...

> And so, maybe we will have to live with what we have currently, and re-iterate on the analyzer and the formatter when the parser is updated. I don't have...

I agree this would be handy in many cases, but I think it would also do the *wrong* or at least confusing things in other cases. See #431 and https://github.com/dart-lang/dart_style/wiki/FAQ#why-does-the-formatter-only-touch-whitespace-by-default...

> most other modern languages and toolings (Prettier.JS, gofmt, clang-format, etc) do this, at least in some form. * Prettier [does not and will not](https://github.com/prettier/prettier/issues/4123): "Closing this as it's definitely...

Leaving a note here that supporting this will likely be much more valuable when we ship the new style (#1253) and every Dart users starts migrating to it. That style...

I'm working on this now. One key question is how the formatter should behave when it can't determine the language version of what it's formatting. Cases where that can occur:...

> I would suggest releasing this first as an optional parameter, so that packages can migrate to it. In this release, would it always apply the short style if you...

OK, I have the DartFormatter class taking a currently optional parameter for the language version. If passed, it uses that language version for parsing. If omitted, it defaults to the...

> Fwiw I do think this should be landed prior to the new formatter being shipped in a stable release, if possible. I think it's harmless to publish a patch...

> We could do this for passing code into `stdin` too, based on CWD instead of the file path. If you are working inside a Pub package directory, the CLI...