ECMAScript 双月报告:TC39 2022年1月会议提案进度汇总

简介: 本次 TC39 会议中仅有 reversible-string-split 提案获得了阶段性进展,由 Stage 0 进入到 Stage 1,其他较受关注的提案如 array-from-async、原生枚举类型,以及在上一次会议中进入到 Stage 1 的 Intl.Segmenter v2 ,在本次会议中都没有取得阶段性进展。

Stage 0 → Stage 1



从 Stage 0 进入到 Stage 1 有以下门槛:

  1. 找到一个 TC39 成员作为 champion 负责这个提案的演进;
  2. 明确提案需要解决的问题与需求和大致的解决方案;
  3. 有问题、解决方案的例子;
  4. 对 API 形式、关键算法、语义、实现风险等有讨论、分析。
    Stage 1 的提案会有可预见的比较大的改动,以下列出的例子并不代表提案最终会是例子中的语法、语义。


Reversible String Split

提案链接:https://github.com/tc39/proposal-reversible-string-split


JavaScript中的 split 方法能够基于指定的分隔符来拆分一个字符串,并将每次拆分的子项保存在一个数组中返回,它接收两个参数:

  • separator,即用于拆分的分隔符,可以是字符串或正则表达式。
  • limit,返回的拆分结果数组的长度,或者也可以理解为进行拆分的次数。

需要注意的是,当你指定了 limit 参数,split 方法的返回值并不会包含由于达到上限而停止拆分的剩余部分,如上面的例子中,剩余的字符串被直接抛弃了:

const str = 'a|b|c|d|e';
// ["a", "b"], 字符串的剩余部分被抛弃了
console.log(str.split("|",2))

这即是此提案所关注的核心问题,因为在其他主流语言中,字符串的 split 方法都将在达到拆分上限时返回余下的部分,如:


Java 代码:

class Playground {
  public static void main(String[] args) {
    String s = new String("a|b|c|d|e|f");
    for(String val : s.split("\\|", 2)) {
      System.out.println(val);
    }
  }
}
// a
// b|c|d|e|f


Rust 代码:

fn main() {
  let v = "a|b|c|d|e|f".splitn(2, "|").collect::<Vec<_>>();
  println!("{:?}", v);
}
// ["a", "b|c|d|e|f"]


Go 代码:

package main
import (
  "fmt"
  "strings"
)
func main() {
  fmt.Printf("%#v", strings.SplitN("a|b|c|d|e|f", "|", 2))
}
// []string{"a", "b|c|d|e|f"}


以及 Python 代码:

print('a|b|c|d|e|f'.split('|', 2))
# ['a', 'b', 'c|d|e|f']

可以看到,Java、Rust、Go、Python 中的 split 方法都会在拆分次数达到 limit 后,返回余下的部分。虽然这里 Python 与其他语言也存在着不同,它会进行 N 次拆分,返回一个 N + 1 长度的数组,而其他语言认为 N 直接代表着返回值数组的长度,因此进行 N - 1 次拆分,返回一个 N 长度的数组。


这些语言和 JavaScript 的 split 方法有一个很明显的区别,即它们的 split 方法返回值由于包含了剩余部分,所以能再次通过 join 方法拼接得到原本的字符串(即 reversible),而 JavaScript 则做不到。这一反转过程可以用以下的伪代码表示:

join(Separator, Value.split(Separator, Limit)) == Value;


为了解决这一问题,同时不影响现有的 split 方法的表现,此提案提出新增一个 splitN 方法,其表现与 Java、Go 语言一致,进行 N - 1次拆分,返回一个长度为 N 的数组,包含字符串的余下部分。

console.log("a|b|c|d|e|f".splitN("|", 2));
// ["a", "b|c|d|e|f"]


而关于为何 JavaScript 的 split 方法会有着如此的表现,作者也在最后提到原因已经无可追溯,能查证的资料表明 split 方法的第二个参数最初是在 1997 年的 Netscape Navigator 4 浏览器中首次支持,而在 ECMA262 中首次明确的记录版本是在 ES3。


结语


由贺师俊牵头,阿里巴巴前端标准化小组等多方参与组建的 JavaScript 中文兴趣小组(JSCIG,JavaScript Chinese Interest Group)在 GitHub 上开放讨论各种 ECMAScript 的问题,非常欢迎有兴趣的同学参与讨论:https://github.com/JSCIG/es-discuss/discussions

相关文章
|
JavaScript
OA项目之我的会议(查询&会议排座&送审)(三)
OA项目之我的会议(查询&会议排座&送审)
|
应用服务中间件
OA项目之我的会议(查询&会议排座&送审)(二)
OA项目之我的会议(查询&会议排座&送审)
|
存储 机器学习/深度学习 监控
ECMAScript 双月报告:TC39 2023年3月会议提案进度汇总
在本次会议中,共有 9 个提案实现了 Stage 推进,其中阿里巴巴主导的 AsyncContext 提案进入到了 Stage 2。另外,有 4 个提案成功进入到 Stage 1,包括 Promise.withResolvers 以及 Class Method Param Decorators 等此前就广受关注的内置方法和语法提案。Stage 2 → Stage 3当一个提案进入 Stage 3 
|
JavaScript 算法 前端开发
ECMAScript 双月报告:TC39 2022年12月会议提案进度汇总
在本次会议中,Intl.Enumeration 提案成功进入到 Stage 4,距离它在 2020 年 6 月的会议上进入到 Stage 1 已经过去了两年半的时间,其它备受关注的提案如 Explicit Resource Management 与 Set Methods也成功取得进展,进入到 Stage 3 阶段。Stage 3 → Stage 4从 Stage 3 进入到 Stage 4 有以
|
存储 Web App开发 JSON
ECMAScript 双月报告:findLast 提案成功进入到 Stage 4
本次会议中,findLast 提案成功进入到了 Stage 4,这是第二个由中国开发者推动进入到 Stage 4 的提案。另外,较受关注的 String Dedent 与 JSON.parse source text access 等提案也在本次会议中取得了阶段性进展。
328 0
ECMAScript 双月报告:findLast 提案成功进入到 Stage 4
|
存储 JavaScript 前端开发
ECMAScript 双月报告:装饰器提案进入 Stage 3
ECMAScript 双月报告:装饰器提案进入 Stage 3
1087 0
|
Web App开发 存储 JavaScript
ECMAScript 双月报告:TC39 2021年4月会议提案进度汇总
来自2021年4月TC39会议关于 ECMAScript 的最新进展。
ECMAScript 双月报告:TC39 2021年4月会议提案进度汇总
|
JavaScript 前端开发 API
ECMAScript 双月报告:Realms 提案进入 Stage 3(2021/07)
7月的 TC39 会议在上周结束了。这次的会议有如 private-in 等提案进入了 Stage 4,Realms、`Object.hasOwn` 等提案进入了 Stage 3,相信很快大家就可以在开发者版本的浏览器、最新版 Node.js 中见到这些 API 了。那么这些提案提供了什么样的能力,我们该如何使用?
ECMAScript 双月报告:Realms 提案进入 Stage 3(2021/07)
|
Web App开发 存储 JavaScript
ECMAScript 双月报告:Realms 提案大改仍没能进入 Stage3
今年因为疫情原因,TC39 的会议频率大为提升,而每一次的会议内容也分散了许多。但是关于提案的讨论热度并不会因为疫情降低,比如这次会议中备受关注的 Realms 提案经过了大改:Realms 在新的提案方案里 Realm 之间无法直接交换除了原始 JavaScript 值(number, string, bigint, symbol 等)和 Callable 以外的 JavaScript 值。
ECMAScript 双月报告:Realms 提案大改仍没能进入 Stage3
|
人工智能 自然语言处理 算法
ECMAScript 双月报告:TC39 2021年12月会议提案进度汇总
作者:@穹心(weixuan.linweixuan)审校:@昭朗(chengzhong.wcz)本次 TC39 会议中,有部分提案在此前会议的讨论基础上进行了更新,如 Intl.Segmenter 提案在 10 月会议中已进入到 Stage 4,在此次会议中更新为 Intl.Segmenter V2 提案,并进入到 Stage 1。另外,较受关注的 proposal-record-tuple、pr