在 ECMA 第 3 阶段使用提案在统计上是否安全？
Is it statistically safe to use proposals in Stage 3 of ECMA?
背景
我指的是 ... 运算符。许多人喜欢并支持执行以下操作的想法：
const obj = { "hello": 1 };
const obj2 = { "world": 2, ...obj };
问题
与典型的 Object.assign 相比，我个人更喜欢这种语法，但最近当我开始在我的项目中使用它时，我遇到了这个 eslint 错误：
Object Spread - Parsing error: Unexpected token
解决办法见以下链接：
这里的问题是要使用这样的语法，我们需要在 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
可以在此处查看有关不同阶段的更多信息：
问题
- S3 中向后兼容性更改的概率是多少？
- S3 撤回了多少提案？
What are probabilities of backwards compatibility changes in S3?
低，没有回到第 2 阶段（见下一个问题）。
How many proposals have been withdrawn at S3 ?
这种情况很少见，但确实会发生。例如，decorators was Stage 3 for some time but has been rolled back to Stage 2. Similarly, class fields were at Stage 3 but moved back to Stage 2 in November (and have since been split [again], where the Class Public Instance Fields & Private Instance Fields proposal went back to Stage 3 again, leaving Static class fields and private static methods 在第 2 阶段）。
您可以通过查看 history on the README.md for https://github.com/tc39/proposals 了解事情的进展情况。不过，这可能有点痛苦。
Is it statistically safe to use proposals in Stage 3 of ECMA?
这取决于您所说的“统计安全”是什么意思。如果您想要高度的确定性，请将自己限制在第 4 阶段。
特别是关于 object rest/spread，它在 Chrome 的 V8 和 Firefox 的 SpiderMonkey 的当前版本中实现（不是在标志后面）。在这里试试：
const a = {answer: 42};
const b = {question: "Life, the Universe, and Everything", ...a};
console.log(b);
在 11 月份的 TC39 会议 the first day 上，状态更新为：
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 阶段。
背景
我指的是 ... 运算符。许多人喜欢并支持执行以下操作的想法：
const obj = { "hello": 1 };
const obj2 = { "world": 2, ...obj };
问题
与典型的 Object.assign 相比，我个人更喜欢这种语法，但最近当我开始在我的项目中使用它时，我遇到了这个 eslint 错误：
Object Spread - Parsing error: Unexpected token
解决办法见以下链接：
这里的问题是要使用这样的语法，我们需要在 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
可以在此处查看有关不同阶段的更多信息：
问题
- S3 中向后兼容性更改的概率是多少？
- S3 撤回了多少提案？
What are probabilities of backwards compatibility changes in S3?
低，没有回到第 2 阶段（见下一个问题）。
How many proposals have been withdrawn at S3 ?
这种情况很少见，但确实会发生。例如，decorators was Stage 3 for some time but has been rolled back to Stage 2. Similarly, class fields were at Stage 3 but moved back to Stage 2 in November (and have since been split [again], where the Class Public Instance Fields & Private Instance Fields proposal went back to Stage 3 again, leaving Static class fields and private static methods 在第 2 阶段）。
您可以通过查看 history on the README.md for https://github.com/tc39/proposals 了解事情的进展情况。不过，这可能有点痛苦。
Is it statistically safe to use proposals in Stage 3 of ECMA?
这取决于您所说的“统计安全”是什么意思。如果您想要高度的确定性，请将自己限制在第 4 阶段。
特别是关于 object rest/spread，它在 Chrome 的 V8 和 Firefox 的 SpiderMonkey 的当前版本中实现（不是在标志后面）。在这里试试：
const a = {answer: 42};
const b = {question: "Life, the Universe, and Everything", ...a};
console.log(b);
在 11 月份的 TC39 会议 the first day 上，状态更新为：
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 阶段。