Remove generalized tear-offs

[munificent]

The language team has decided the generalized tear-off feature looks like it won't work as well as originally hoped, so we're going to take it out. Fortunately, it was never fully implemented and it appears to be completely unused within Google (both strong signs it wasn't a highly desired feature).

In the future, we hope to support constructor tear-offs with a more natural syntax. In the meantime, the tools that have implemented generalized tear-offs should remove support for it.

Tracking issues:

• Language spec (Remove generalized tear-offs from the language spec #27519)
• VM, mark as deprecated (VM: Mark generalized tear-offs as deprecated #27742)
• VM, desupport (Remove generalized tear-offs from the VM #27520)
• Analyzer (Remove generalized tear-offs from analyzer #27523)
• Make sure changelog has an entry for this

[dgrove]

@bwilkerson I believe there's analyzer work as well (not strictly required, since it's behind a flag). Correct?

[munificent]

Thanks, added one for that too.

[mit-mit]

Moving to 1.22 per release discussion, deprecation warning will happen in 1.21 (see #27742).

[mit-mit]

Marking spec update complete in the checklist up top.

[trinarytree]

Part of the reason for lack of use may have been that constructor tear-offs were not considered const:

class A {}

void main() {
  const c = new A#;  // error: expression is not a valid compile-time constant
}

This made it impossible to use such tear-offs as factories in the version of Angular's DI system that demands constants. See #24845.

munificent, you said in that issue that we don't have to worry about that issue because this tear-off feature is being removed, but that may be circular reasoning: That issue made tear-offs unattractive => the feature wasn't used much => you think you should remove the feature => we should keep tear-offs unattractive.

[munificent]

That issue made tear-offs unattractive => the feature wasn't used much => you think you should remove the feature => we should keep tear-offs unattractive.

My logic isn't that I think we should remove generalized tear-offs. That decision has already been made. The logic is thus:

This issue relies on generalized tear-offs → Generalized tear-offs are being removed → We can close this issue. :)

The larger picture here is that the language team does want to add a better story for:

• Closurizing constructors
• Creating closures for other tiny common operations where an explicit closure feels too verbose

Generalized tear-offs handled the former, but with a not great syntax. It only handled a subset of the latter, again with a not great syntax. In some of the cases it did handle, the result was more verbose than an explicit closure, again because of the not great # syntax.

We think we have some ideas on how to do something notably better than generalized tear-offs. And, since they weren't in use anyway, we decided to remove them to simplify things and avoid having multiple overlapping ways to accomplish the same thing.

[munificent]

Oh, to your original comment about canonicalization. If/when we introduce syntax for constructor tear-offs, we'll take canonicalization into account. I don't have a lot of expertise on it, but we'll make sure there's time to iterate on it with the Angular folks and users like yourself so that we don't ship a feature that doesn't handle important use cases.

[mit-mit]

Marking VM complete.

[mit-mit]

Changelog updated in #28221

[mit-mit]

All done, closing!