#Unordered Async Iterator Helpers S1

中文标题：无序异步迭代器助手

#JavaScript 无序异步迭代器助手提案

阶段： 1

提案发起人： Michael Ficarra

作者： Michael Ficarra

#向委员会所做的演示

• 2024 年 7 月：阶段 1

#背景

迭代器助手 MVP 提案 的早期形式包含了 AsyncIterator.prototype 上每个迭代器助手 MVP 方法的变体。这些方法被规定为与基于生成器的朴素实现行为一致，其理念是，对其行为的推理就像说“在最先想到的实现中这会做什么”一样简单。不幸的是，这意味着异步迭代器助手变体继承了生成器的不良排队行为：无论生成的异步迭代器在不等待未决 Promise 的情况下被 next() 调用多少次，底层迭代器都永远不会有多于一个未决的 next()。高层次的结果是，支持（并能受益于）并发 next() 的异步迭代器，在被迭代器助手 MVP 提供的任何转换方法转换后，都会失去这种支持。为了争取时间解决这个问题，而不阻碍同步迭代器助手，我们把异步迭代器助手拆分到了它们自己的提案。注意：我非常感谢社区成员参与进来，迫使我们更深入地思考这个问题，花费额外时间，而不是仅仅做简单的事情！

后来，在制定异步迭代器助手提案，并试图最大化异步迭代器 MVP 方法所允许的并发性时，我们发现，放弃排序约束可以允许对可用并发性进行更高效的利用。预期许多用例（可能大多数）也能够放弃排序约束。在异步迭代器助手提案中曾简要探索过无序助手，但由于设计空间很大，并且为了不阻碍该提案，它们被推迟到以后的提案中，就像异步迭代器助手从同步迭代器助手提案中被推迟一样。这就是那个被推迟的提案。

#提案

异步迭代器助手提案在 Iterator.prototype 上引入了一个 .toAsync() 方法，将迭代器提升为以 AsyncIterator.prototype 为其原型的异步迭代器。AsyncIterator.prototype 具有与 Iterator.prototype 相同的所有方法名称。本提案采用类似的方法。

AsyncIterator.prototype 获得一个名为 .unordered() 的方法，将异步迭代器提升为以 UnorderedAsyncIterator.prototype 为其原型的无序异步迭代器。UnorderedAsyncIterator.prototype 与 Iterator.prototype 和 AsyncIterator.prototype 具有相同的所有方法名称（可能除了 .toAsync() 和 .unordered()？），但它们的实现能够通过可能以与提供顺序不同的顺序解析所提供的 Promise 来实现更高的并发性。

我们可以从 alexpusch/rust-magic-patterns/rust-stream-visualized 中看到有序和无序转换之间吞吐量差异的可视化。

由于在不存在对 .next() 的并发调用时，无序助手无法提供优势，因此本提案中消耗迭代器的方法（.some()、.forEach() 等）将依赖于并发控制提案。

#未决问题

• .toAsync() 和 .unordered() 的名称是否应该更好地匹配？
  • AsyncIterator.prototype.toUnordered()？
  • Iterator.prototype.async()？
• UnorderedAsyncIterator.prototype 是否应该具有 .unordered() 方法？
  • 同样地，{Unordered,}AsyncIterator.prototype 是否应该具有 .toAsync()？
• 是否需要并发参数？
  • 并发为 1 基本上就像调用有序助手（不好）

#考虑过的替代方案

#每个助手的 -Unordered 变体

这更糟，因为它允许在无序助手之后链接保持顺序的助手，从而失去并发优势。命名也偏向于有序助手，即使在任何可能的地方都应该鼓励使用无序助手。