HE Shi-Jun

It seems WHATWG is very like a Trust of 4 players (google, apple, mozilla and microsoft), because as the "Qualifying Entity" @annevk gave, even the other browsers in the caniuse...

This brings ambiguity. Theoretically, `42@foo` could return anything, include function. In such case, `(42@foo)()` is same as `42@foo()()` but not `42@foo()`. It would be even interesting if you consider `new...

As I understand, case like `foo((let bar = buz()) && bar.x && bar.y)` could (should) be solved by do expression proposal.

@dou4cc 关于shortcut-promise不知道你具体想问什么？ async iteration 93 问题主要是 async iter 中 yield 的行为。从个人偏好来说，zenparsing 的方案（即只在 for await of 中 unwrap，如果你要手写 next，得自己处理）我觉得也是可以接受的，但现在的方案（yield 等价于 yield await）也没有什么大问题，至少对绝大多数程序员和绝大多数use case是比较好的。

要看你怎么定义“不一致”。假若我们把 iterator 和 async 看成两个正交的特性，那么 yield 等价于 yield await 确实比较奇怪。但是我想 domenic 的 slide （https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM ）已经给出了比较充分的理由。第22页上讲了他反对不unwrap的理由。尽管我也说了，我认为不unwrap是可以接受的，但是以我的看法，这两种行为至多是各有千秋，很难说哪个一定更好。既然tc39已经开会决定了，那么在没有其他更强有力的理由的情况下，是很难改变决定的。 另外你说“对于AsyncIterator的同步版本Iterator，Generator能做到和手写Iterator一样，AsyncGenerator却不能”，是指什么？

> 你点进去，我想让你评价我在issue里的另一种实现。 你的另一种实现的差异是什么？就是 Promise.resolve(1).then(f) 中的 f 会同步执行么？

> 不一致指：AsyncGenerator对应AsyncIterator，手写AsyncIterator能next出promise的value，甚至被for await支持，却不能用友好的AsyncGenerator做到，这和AsyncFunction不同，AsyncFunction不能返回两层promise是因为手写promise也搞不出两层。 这个事情 domenic 的解释是这（手动弄一个Promise）属于打破 protocol 的情况，所以不能算“不一致”。就好像说 iterator 要求 next() 得到 {done: true} 之后不能再返回 {done: false: value: ...} 了，但你手写当然可以写出这样的。 固然，要更严谨一点，你可以要求它在遇到这种情况时扔 TypeError，否则总会有人故意写这样打破 protocol 的 async iter。虽然我不觉得这是很大的问题，但是确实你可以去开个issue，😜 > 我十分反对domenic对双层promise的理解，Promise.resolve({value:Promise.resolve(),done:true})就不是双层promise，他把那个done当什么？考虑到搞出AsyncGenerator的动机就是想在generator里await，unwrap什么的就别搞，没有困扰、歧义。 从正交角度看确实是这样的。所以从理论简单性上，我也略微倾向于zenparsing 的选择。...

> 那个repo不是我的，我只是让你看那个issue，里面有我的实现，不仅不强制异步，而且不支持throw，flatten时直接脱光，把result暴露出来。 > 这样就没有传染性了，不过不支持throw。 我对具体的实现其实兴趣不大。如果要重新发明轮子，首要的是语义上（而不是实现上）有什么不同，目的是什么。 总是异步这个事情，如我所说，不是 promise 的发明，node callback 也是如此（原因我就不再解释了）。一致的错误处理这两者也是一致的（只是node callback限于异步callback的限制，不能throw自动传播，必须自己手动传递，所以比较蛋疼）。 如果要重新发明轮子，采用不一样的语义（不总是异步，不支持 throw），得首先说明为什么你要采用和 promise/node callback 相背离的语义，然后，先不说你的理由是否站得住脚，即使有一定道理，也要考虑实践上这样做对即有代码的后果，如果好处抵不上成本，那也很难得到支持。

> 搞泛函编程是避不开传染的。 所以是准备先黑一波haskell么？ > 我说了需要map的是个AsyncGenerator实现的队列。既然map，队列各元素确实独立，但这些元素是迭代生成的，因为上文提到的传染性，这些迭代得是异步的。 Array.prototype.map 当然只适用于数组。序列本来就不是用数组处理的。比如同步generator返回一堆promise自己弄。无论是sync generator还是async generator都可以自己写一个用于它的map函数或者用observable呗（按照当前observable草案在异步generator上会有[Symbol.observable]方法帮你转成observable）。如果是最简单的case，在异步函数里用 for await of。 所以我不知道问题在哪里？你总不能指望拿Array.prototype.map包打天下吧。 > 不仅不一致、不正交，连对称性都搞没了 我之前已经强调过，你不能光追求理论上的性质，而缺乏实际use cases的支持。 说实话，虽然 iterator 协议允许你通过 next(value) 形成双向通讯，但是（除了当初模拟async/await）我没见过真的 use cases。手动调用 next 本来就非常罕见，何况在 function.sent 进入标准之前，这协议还是不完善的。你如果要喷对称性，不如喷这个。

`cp dist/github.js.map dist/github.user.js.map` seems not correct, I think we should revise the second uglify command.