javascript - 在 ECMA 第 3 阶段使用提案在统计上是否安全？

Question

背景

我指的是 ... 运算符。许多人喜欢并支持执行以下操作的想法:

const obj = { "hello": 1 };
const obj2 = { "world": 2, ...obj };

问题

与典型的 Object.assign 相比，我个人更喜欢这种语法，但最近当我开始在我的项目中使用它时，我遇到了这个 eslint 错误:

对象传播 - 解析错误:意外标记

这个问题的解决方案可以在下面的链接中看到:

• https://github.com/eslint/eslint/issues/4052
• https://eslint.org/docs/1.0.0/user-guide/configuring

这里的问题是，要使用这样的语法，我们需要在 eslint 上启用 experimentalObjectRestSpread 标志。此标志附有以下警告:

experimentalObjectRestSpread - enable support for the experimental object rest/spread properties (IMPORTANT: This is an experimental feature that may change significantly in the future. It’s recommended that you do not write rules relying on this functionality unless you are willing to incur maintenance cost when it changes.)

在验证提案后，我意识到它处于第 3 阶段:https://github.com/tc39/proposal-object-rest-spread

有关不同阶段的更多信息，请参见此处:

• http://2ality.com/2015/11/tc39-process.html

问题

• S3 中向后兼容性变化的概率是多少？
• 在 S3 上撤回了多少提案？

Answer 1

What are probabilities of backwards compatibility changes in S3?

低，没有回到第 2 阶段(见下一个问题)。

How many proposals have been withdrawn at S3 ?

这种情况很少见，但确实会发生。例如，decorators有一段时间是第 3 阶段，但已回滚到第 2 阶段。同样，类字段处于第 3 阶段，但在 11 月回到了第 2 阶段(并且此后 [再次] 被拆分，其中 Class Public Instance Fields & Private Instance Fields 提案回到再次进入第 3 阶段，将 Static class fields and private static methods 留在第 2 阶段)。

您可以通过查看 history 了解事情的进展情况。在 README.md 上 https://github.com/tc39/proposals .不过，这可能会有点痛苦。

Is it statistically safe to use proposals in Stage 3 of ECMA?

这取决于您所说的“统计安全”是什么意思。如果您想要高度的确定性，请将自己限制在第 4 阶段。

特别是关于对象 rest/spread，它在 Chrome 中的 V8 和 Firefox 中的 SpiderMonkey 的当前版本中实现(不是在标志后面)。在这里试试:

const a = {answer: 42};
const b = {question: "Life, the Universe, and Everything", ...a};
console.log(b);

关于 the first day 11 月 TC39 session 的状态更新是:

KCL: Is Object spread possible to make it into es2018?

BT: If someone can make a PR and get it on the January agenda then we can put it in.

...听起来很可能是在 1 月份的第 4 阶段。