Optional `new` and `const` for Dart 2 (meta issue)

[lrhn]

Dart 2 will make new and const operators optional in some cases. The feature is described in https://github.com/dart-lang/sdk/blob/master/docs/language/informal/implicit-creation.md.

This feature needs support from, at least, the common front-end. The kernel compiler can, and likely will, generate the same kernel code whether an optional new or const is present or not, so back-ends should be unaffected. Effectively, the kernel (or even the parser) can perform automatic "new/const" insertion on the program, as soon as it can recognize an invocation as referring to a constructor rather than a static method.

The feature extends the grammar with syntax that wasn't previously valid, so the formatter likely needs to be prepared for it.
The analyzer may need to be prepared for the different syntax as well.

We will not back-port this feature to non-kernel based backends.

• Front-end (Front-end handling of optional new and const. #30922)
• Formatter (Support optional new and const. dart_style#652)
• Analyzer (Analyzer handling of optional new and const. #30923)
• Angular: Angular code generator needs to be verified to work with optional new and const #33221
• Communication when the feature is ready
• Remove new and optional const from SDK code
• Specification (Include specification of optional new and const in Dart 2 language specification. #30924) - this is dartLangSpec.tex, the feature specification has already been landed.

[bwilkerson]

@munificent I don't think there's any work for the formatter, but it would be good to double check that.

[eernstg]

About the need to adjust the formatter, and possibly other tools: The grammar had to be extended with support for a new construct, namely

constructorInvocation ::=
    typeName typeArguments '.' identifier arguments

and that construct is then used in a couple of places. The point is that we can now have things like C<int>.someName(42), and the ability to have actual type arguments after the class name is new. So every tool that has a parser which hasn't already been updated to handle this will need an update.

[bwilkerson]

Yep, but the formatter uses the analyzer parser, so I think it's probably fine.

[munificent]

Turns out there is one case the formatter needs to handle:

SomeGenericClass<int>.someNameConstructor();

I added support for that in dart-lang/dart_style@b89b572.