Suggestion: Experimental Support for ECMAScript Stage 1/2 Proposals

[rbuckton]

We have generally chosen to only support ECMAScript Stage 3 and later proposals in TypeScript, with few exceptions. I propose that we choose to adopt earlier stage proposals through a combination of experimental switches and targets:

• By default, for any early stage proposal we do not scan, parse, check, or emit any related syntax.
• When an experimental feature is enabled, write a diagnostic warning message to the output.
• Add an --experimentalStageNProposalName switch for any early-stage proposal we opt to support to enable scan, parse, check, and emit for that proposal.
• Add an --experimentalStageN switch to enable all experimental proposals in that stage.
• Add a --target esstageN target to disable down-level emit for any proposal in that stage.
• If a proposal advances between stages and changes syntax or runtime semantics, we can differentiate between each stage of that feature with a different switch.
• Once a proposal has advanced to Stage 3 or beyond, we can deprecate and eventually remove any outdated experimental switches in each release cycle.
• If necessary, we could consider restricting these experimental features to @next builds only.

Note that this differs from the behavior of the current --experimentalDecorators switch in that we always parse decorators today, but issue a warning that is disabled with the switch. For this proposal we would never parse experimental features if the switch is disabled, and always issue a warning when it is enabled.

This would allow us to get valuable early feedback in TypeScript for various ECMAScript proposals as they advance while reducing the likelihood that developers become dependent on a feature whose experimental nature can change without notice due to a silently ignored warning.

[gcnew]

I'm afraid adding and supporting the proposed infrastructure as well as the to-be-implemented proposals would add a significant burden on the team.

Personally, I'd prefer an infrastructure for experimental/breaking type-safety features, as it would be a greater benefit for the community. Good transpiler solutions exist besides TypeScript, however, the type system side is much harder to develop, and as such, the available alternatives are much more scarce.

[kitsonk]

There are some Stage 1 and Stage 2 proposals that languish for extended periods of time and then have bursts of activity. They often introduce breaking changes without considering the consequences (as is appropriate for a proposal like that). Sometimes the proposal are in an unimplementable fashion, or are not comprehensive in their implementations.

Functional proposals are often easier to deal with by downstream users, as you can easily version through some sort of polyfill and then choose when to introduce those breaking changes. Of course TypeScript doesn't deal with functional proposals, only syntactic ones.

Decorators are a great example, while I have appreciated them being part of TypeScript, we are now faced with how to we migrate to the final spec.

While there might be some benefits into "cutting your teeth" on the proposal, it feels like a false economy, because just as many issues could be encountered as could be solved with downstream changes.

I am sure the team has considered this, and I know folks know the proposal well and what is outstanding, but looking at #16 and how it would fit this model and what sort of changes to the ECMAScript proposal would cause re-work or wasted work. Or the more challenging situation, that no matter how many warnings and caveats you put on it, those of us in user land end up depending on it for critical functionality for our projects and then become hugely frustrated at the core team for loading bullets into our foot gun. TypeScript's main purposes is to keep us from shooting ourselves in the foot.

[mhegazy]

Based on the discussion in #19169, our current policy stays unchanged. We will only include Stage 3+ features; for Stage 0, 1, and 2 a PR/branch would be the right way to expose these features, but should not be included in an official/nightly release.