【提案讨论】Iterator Methods

[Alan-Liang]

一些链接：Proposal（目前 Stage 2），2019/1/31 进 stage 1，2019/7/24 进 stage 2，stage 2 slide

我认为有几个问题：

难以完全 polyfill

在连 %IteratorPrototype% 都没有的环境里（比如 IE），像 regenerator-runtime 这样的库会自己补一个 IteratorPrototype，而这些 Prototype 必然是没有 Iterator Methods 的。比如说这样：

// library/src/index.js (ES6)
import 'regenerator-runtime'
export function* g () {
  let i  = 0
  while (true) yield i++
}

// library/lib/index.js (ES5)
// (省略一大堆)
exports.g = g;
require("regenerator-runtime"); // 注意这里可能已经被 webpack 打包了，不是简单的 require 的形式
var _marked = /*#__PURE__*/regeneratorRuntime.mark(g);
function g() {
  var i;
  return regeneratorRuntime.wrap(function g$(_context) {
    while (1) {
      switch (_context.prev = _context.next) {
        case 0: i = 0;
        case 1: _context.next = 4; return i++;
        case 4: _context.next = 1; break;
        case 6: case "end": return _context.stop();
      }
    }
  }, _marked);
}

// script.js
import { g } from 'library'
import 'core-js/some-polyfill-on-iterator-methods'
for (const x of g().map(x => 2 * x).take(5)) console.log(x)

这时候分几种情况：

• 环境有 %IteratorPrototype% 并且有 Iterator Methods：polyfill 不起作用，一切正常运行
• 环境有 %IteratorPrototype% 但是没有实现 Iterator Methods：polyfill 作用到 %IteratorPrototype% 上，被 polyfill 之后正常运行
• 环境没有 %IteratorPrototype%：分情况
  • library 用的打包过的（内置的）regerator-runtime：见下
  • library 用的是 require('regenerator-runtime') 的形式：细分
    • library 用的和外面的是一个版本（即没有 node_modules/library/node_modules/regenerator-runtime）：core-js 理论上可以想办法把 polyfill 打到 regenerator-runtime 上，正常运行
    • library 有自己的一个版本（即有一个 node_modules/library/node_modules/regenerator-runtime）：见下

上面的“见下”，又需要分情况：

• core-js 比 regenerator-runtime 先加载：core-js 提供一个 %IteratorProtype%，regenerator-runtime 用上它，正常运行
• core-js 比 regenerator-runtime 晚加载：core-js 找不到 regenerator-runtime，打不上 polyfill，卒

core-js 比 regenerator-runtime 晚加载的情况是有可能发生的，比如这样：

// src/a.js
import { g } from 'library'
import './b'
console.log(g().next())

// src/b.js
import { g } from 'library'
for (const x of g().map(x => 2 * x).take(5)) console.log(x)

// lib/a.js
var g = require('library').g // regenerator-runtime
require('./b') // core-js/some-polyfill-on-iterator-methods，比 regenerator-runtime 晚
console.log(g().next())

// lib/b.js
require('core-js/some-polyfill-on-iterator-methods') // 按 usage 自动插入
var g = require('library').g
// ...

这显然是一个行为非常奇怪且复杂的 polyfill。

与现有说明不符，容易造成误区

Iterator 接口只要求一个 next 方法，一般用到的 Iterator & Iterable 也只要求两个（next() 和 [Symbol.iterator]），看样子 champion 还不想让 Iterator.from() 作为一般的链引发，就会造成有人会实现一个这样的东西当 Iterator 传给别人（我开始就这么干过）：

let i = 0
return {
  next: () => ({ value: i++, done: false }),
  [Symbol.iterator] () { return this },
}

然后用的时候发现可以完全正常 for-of，也可以正常 next，但是只要上 Iterator Methods 就 undefined is not a function。Champion 在 slides 里说 “Iterators that don’t extend %IteratorPrototype% or %AsyncIteratorPrototype% are more or less not proper iterators”（第三页），但是现在 MDN 上的示例就是没有继承 %IteratorPrototype% 的……

---

我认为这两个问题的根源在于，Iterator & Iterable 本来是完完全全的 duck-typing，如果要往里头塞方法（必然会用到 prototype），除非往 Object.prototype 里塞（Iterable 还可能是 null-proto object 呢），要不打破原有的接口定义，要么定义一个新的接口（或者包装对象，即 Iterator.from()），否则就会导致混淆。

几个我能想到的解决方法，都不完美：

• 更新 regenerator-runtime 使得它的 polyfill prototype 支持 Iterator Methods：但是 1）如果再往 %IteratorPrototype% 上加方法还是会出问题，2）没法保证所有 package 都更新；
• 在所有转译过的文件最开头都加一个 require('core-js/some-polyfill-on-iterator-methods')：1）体积，2）拦不住别人不转译代码啊；
• 重新定义 Iterator.from() 的语义，从现在的仅仅是一个 %WrapForValidIteratorPrototype% 改成完整的 %IteratorPrototype%，推荐使用 Iterator.from() 作为链引发（即 BFS 提到的“I would expect a corollary that Iterator.from is turned into a real iterator whether than something with the iterator protocol”）：还是解决不了第一个问题里的行为不一致性（但是可以通过 linter 来解决）；
• 用 userland 的库来实现 Iterator.from(gen())...：这样的话也没 proposal 什么事了。

以上。