【新提案】双端迭代器和解构

[hax]

提案repo：https://github.com/hax/proposal-deiter

计划在下周的TC39会议上争取进stage 1。

当前解构中...rest必须在最后一个参数的位置，此提案允许...rest出现在任何一个位置（不过仍然只能出现一次）。

比如 let [first, ...rest, last] = [1, 2, 3, 4]，结果first为1、rest为[2, 3]、last为4。

其底层机制使用双端迭代器。

对于 let [first, ...rest, last] = iterable 不是调用 iterable[Symbol.iterator]() 而是调用 iterable[Symbol.deIterator]()，其应该返回一个双端迭代器。双端迭代器应支持从两端进行迭代，next('back')表示从尾端迭代：

const iter = [1,2,3,4,5].values() // 这里假设values方法将升级为支持双端迭代
iter.next() // {value: 1}
iter.next('back') // {value: 5}
iter.next() // {value: 2}
iter.next('back') // {value: 4}
iter.next('back') // {value: 3}
iter.next() // {done: true}
iter.next('back') // {done: true}

这样 let [first, ...rest, last] = iterable 差不多相当于：

const iter = iterable[Symbol.deIterator]()
let first = iter.next().value
let last = iter.next('back').value
let rest = [...iter]

Userland要实现双端迭代器，需要使用function.sent（stage 2）特性。

Array.prototype.values = function *values(array) {
  for (let start = 0, end = array.length; start < end;) {
    if (function.sent === 'back') yield array[--end]
    else yield array[start++]
  }
}

以上。

[hax]

一些在进入stage1之后需要进一步探讨的问题：

是否需要引入双端迭代，还是用更简单的方式将let [first, ...rest, last] = iterable直接按照以下处理？

let [first, ...rest] = iterable
let last = rest.pop()

我个人倾向于引入双端迭代，因为对于大数组或者range(1, 100000)来说，先转成数组需要遍历所有item，毫无必要。尤其是当你不需要rest的时候，语法 let [..., last] = iterable可以直接按照以下处理：

let last = iter.next('back')
iter.return() // 结束迭代

此外，将来也许可以扩展出 let rest = iter.next('rest') 这样允许 let [a, *b, c] = range(1, 10)中的b为range(2, 9)。

是否需要单独的 Symbol.deIterator ？

如果不引入 Symbol.deIterator，仍然使用 Symbol.iterator，我们需要某种方式能判别 iterable[Symbol.iterator]() 的返回值是一个双端迭代器。比如其prototype为DoubleEndedIterator.prototype 而不是 Iterator.prototype。但这里涉及到如何在写 generator 时声明其得到的 generator object 继承自 DoubleEndedIterator。

一个方式是这样：

class X {
  *_deIter() { ... }
  [Symbol.iterator]() {
    const it = this._deIter()
    Object.setPrototypeOf(it, DoubleEndedIterator.prototype)
    return it
  }
}

如果有 decorator，就会比较简单：

class X {
  @deiter *[Symbol.iterator]() {...}
}

如果没有实现双端迭代，[..., last] = iterable 是 fallback 到简单方式，还是直接报错？

我倾向于直接报错。这样确保可预期的性能。同时现有builtin的绝大部分可迭代对象都可以支持双端迭代，所以应该没有什么大问题。

解构项不够时的语义

let [..., a, b] = [1] 的结果是 a 为 1 还是 b 为 1（另一个为undefined）？两者似乎都有道理。Ruby、Coffee是 a 为 1。注意这里的选择也会对下面执行顺序的问题产生影响。

执行顺序

let [..., a, b] = iterable，当调用第二个next('back')时扔异常，结果会怎样？a或b是否有值？还是都undefined？

let [a=console.log(1), ...[b=console.log(2)], c=console.log(3), d=console.log(4)]的执行结果是1、2、3、4还是1、4、3、2？

[septs]

请问本提案能解决那些典型 use case？

[hax]

@septs 首先因为python、ruby、coffee早就支持 [a, ...b, c] = iter类似语法，甚至最近rust也支持了，所以大家本身就期待可以这样写。从2011年以来到现在10年了，不完全统计在es-discuss邮件列表里被提出此语法已经很多次了。

然后具体的case，除了直接解构拿后面的项，最主要的就是函数参数，末尾固定参数，前面有不定参数：

string.replace(pattern, (fullMatch, ...submatches, matchIndex, fullString) => {
  // `matchIndex` is always the second to last param (the full string is the last param).
  // There may be many submatch params, depending on the pattern.
})

常见还有node.js里常见的固定末尾参数为callback，而前面为不定个数参数；某些库的api可能末尾固定参数为一个option对象，前面为不定个数位置参数。

[septs]

OK

1. iterator.next(action?: string) 我不觉得是个好的选择，使用 Symbol？

2. @@deIterator，选择 de- 作为词头是否合适？
   个人主观认为 @@reversedIterator 利于理解和表述。

3. 与 @@deIterator 是否应该有与其配套的 @@deIterable？

[hax]

@septs

1. symbol在现有标准中只用作特定协议，也就是它是作为对象上的键值存在的，目前还没有用作一般参数的先例。而字符串参数在JS里很常见（比如[Symbol.toPrimitive](hint?: string)）。当然我们可以尝试建立这个先例，不过我感觉不容易得到委员会一致同意。

2. de是double-ended的缩写（传统上双端队列double-ended queue用简称deque），现在这个名字double-ended iterator是借鉴rust的。我们也可以不要缩写，改用完整写法：Symbol.doubleEndedIterator，如果不嫌长的话。其实我估计委员会最后可能会要求用全称的，只是写提案的时候试试看先写成缩写。😅

   reversedIterator不准确，无法表达双端的含义。另一份stage1的提案会使用Symbol.reversedIterator来返回反向迭代器。反向迭代器其实和普通迭代器是一样的。另一种名称是bidirectionalIterator，不过大家可能会认为它应该是支持prev()的迭代，更类似cursor，而且在js里可能有一些问题（比如已经到最后得到{done:true}了还能不能回退）。

3. Iterable只是一个概念，定义就是具有[Symbol.iterator]()方法且返回符合iterator约束的对象，但并没有@@iterable。那么照此来说，也可以有DEIterable，定义就是具有[Symbol.deIterator]()方法且返回符合deiter约束的对象。

[xiaoxiangmoe]

const [, ...rest] = arr

代表去掉第一个元素

const [...rest, ] = arr

那这个呢？

[hax]

一般而言，尾随逗号在js里是忽略的，因此和没有尾随逗号是一样的。比如 [1,] 和 [1] 一样得到一个长度为1的数组。这可能看上去有点不对称，不过恐怕也只能如此。所以，const [...rest, ] = arr大概只能和 const [...rest] = arr 一样。

[zhenzhenChange]

想到了最近遇到的一个场景，我当时就本能的想着写：

const [head, ...other, tail] = list // list 是一个数组

然后跑起来发现直接报错了，喔，原来还不支持。
这个场景是渲染面包屑组件（Breadcrumb），只取头尾，剩下的省略（或者更多），效果就像这样：

或者类似分页组件

后面只能先unshift再pop了，或者list[0]和list[list.length-1]的取，不过在此之前还得需要判断我list的长度够不够3条。。。
最后的代码大概是这样子：

const head = list[0]
const tail = list[list.length - 1]

const items = list.slice(1, list.length - 1)

喜欢这个提案！

[hax]

我计划在下次TC39会议（2022年7月）对本提案做更新陈述。主要有几个想改动（和细化）的点。

第一，将 "back" 改为 "last"。一开始用 next("back") 是沿袭了 Rust 的 nextBack()，而Rust可能是沿袭了 C++ 的 vector/deque 传统叫法，front/back 表示 the first/last element。但 JS 里我们并没有这个用法。使用 "back" 造成大家很容易混淆双端迭代（double-ended）和双向（bidirectional）迭代。故而考虑改为 "last"，这样与 lastIndexOf/findLast 以及未来可能在 Iterator helpers 里加入的takeLast/dropLast/findLast的用法里的 last 也是一致的。

第二，考虑使用单独的 nextLast() 而不是 next("last")。一开始采用 next() 参数形式，是因为考虑可以利用现有的 generator 机制来写双端迭代。但它依赖 function.sent 提案（否则第一次传入的参数无法得到）。而 function.sent 提案本身有一些问题，我花了很长时间（近3年）考虑如何解决。直到上一次会议上我做了 function.sent 提案更新，希望能改为 receive param 形式。尽管我认为 recieve param 形式才是解决 functiont.sent 提案的唯一正确方式，但看来在 TC39 有比较大的阻力。既然推进 function.sent 提案遥遥无期，为了能推进双端迭代，我希望弱化双端迭代对 function.sent 的依赖关系，把「能用 generator 写双端迭代」的需求从双端迭代提案本身中摘出去，作为 use case 留给 function.sent 或后续提案去处理。既然如此，就不如采用显式的方法 nextLast()，可能有助于缓解一些人对通过 next() 传参的不适（尽管 ES6 iterator 从一开始就可以接受参数，但有些 TC39 似乎从概念上觉得 next() 传参就是 confusion）。

第三，判定是否是双端迭代器的机制（当双端解构实际调用了一个非双端迭代器应该扔TypeError）。在最初，我引入了 @@deIterator，故而可以用是否有该 symbol 判定。但我感觉引入额外的 well-known symbol 可能必要性不高。几乎所有时候，如果一个 Iterable 已经有双端迭代，则其 @@iterator 和 @@deIterator 总是一样的（因为双端迭代也可以作为传统正向迭代来用嘛）。反向迭代（有另一个提案，引入了@@reverseIterator）也可以通过双端迭代来生成。（支持正向迭代和反向迭代，却无法支持双端迭代的 use cases，我认为是几乎没有的。）所以考虑不要引入额外的 well-known symbol。原本是考虑要有单独的属性（比如 iterator.supportBack 或简单的 iterator.back ）来标明，既然根据上一点，有nextLast方法，则直接以迭代器上有没有 nextLast 方法来判定就好了。

第四，其他如现有内建迭代器升级到支持双端基本没有啥特别大问题，Iterator helpers升级到支持双端有一些小问题，留待以后再说。

[LongTengDao]

我比较好奇的是，对应的生成器函数该怎样写？

[hax]

见 https://johnhax.net/2022/deiter/slide#52 开始的5页

[LongTengDao]

function.back 如何？

[hax]

function.sent 都可能推进不下去，不要说单独为了双端迭代增加一个 meta property 了。此外关于 function.sent 的语法，看 https://johnhax.net/2022/function-sent/slide#23 ，它面临的问题也适用于此。