Closed Gvozd closed 6 years ago
@Gvozd Hmm, Safari Technical Preview the same result as in Chrome Canary.
As I know yield
does always await
in async generators
https://tc39.github.io/proposal-async-iteration/#sec-asyncgeneratoryield 11.4.3.7.8.b Also discussion https://github.com/tc39/tc39-notes/blob/master/es8/2017-05/may-25.md#15iva-revisiting-async-generator-yield-behavior
Conclusion/Resolution Go with option 3: yield has the semantics of yield await in an async generator
@gskachkov Thanks I read discusion and slides, and it became clear to me
It seems that Async Generator Rewrite is not entirely actual. And Chrome and Safari correctly supported discusion resolution.
Also after read slide 27, I got additional code with problem behavior @gskachkov, please tell what result you have in Safari
(async () => {
const iterator = {
i: 0,
next() {
if (this.i >= 3) {
return {done: true};
}
return {
value: Promise.resolve(this.i++),
done: false
};
},
[Symbol.asyncIterator]() {
return this;
}
};
for await(const i of iterator) {
console.log(i);
}
})();
babel-node execution log - not correct for slide 27
0
1
2
Chrome Canary log - correct for slide 27
Promise {<resolved>: 0}
Promise {<resolved>: 1}
Promise {<resolved>: 2}
@gvozd This has been fixed in Babel 7 (currently Beta) so Babel's implementation should be compliant with the other implementations now.
@Gvozd I'm receiving following results in Safari Technical Preview:
Promise {status: "resolved", result: 0}
Promise {status: "resolved", result: 1}
Promise {status: "resolved", result: 2}
@Jamesernator I check with @babel/core@7.0.0-beta.32
My first example works correct, like Chrome/Safari
But second example work not like Chrome/Safari, and for-await resolve my manual promise result
Also I was surprised, that transform-async-to-generator
moved from stage-3
, and disabled by preset-env
I use node v9.2.0, that support async
functions, but not for-await
loop, and my node need only for-await
transform(if possible), or both transformation
.babelrc
{
"presets": [
["@babel/env", {
"targets": {
"node": "current"
},
"include": [
// without this `for-await` not worked !!!
"transform-async-to-generator"
]
}],
"@babel/stage-0"
]
}
async iterators is stil experimental feature in v8, so if you need fully support you can switch on it by
node --harmony-async-iteration
But it is not related to the current repo, it is better to close this issue.
pedantic correction :) that feature is shipped in v8 for some time, though Node.js hasn't updated to a version where it is shipped yet (It is staged since Node.js 9 and can be enabled with just --harmony
)
@caitp Good to know! I thought I had to wait for node to use 6.3 before I could get at this goodness!
@gskachkov Thanks for your help I got the answers I needed
Let me remove AsyncGeneratorRewrite, since it is causing confusion. Glad this all worked out though.
@domenic AsyncGeneratorRewrite.md is good idea - for me it was more understandable than spec I'll try to correct it for the actual behavior
Nah, it's OK, I'd rather not maintain two sources of truth in this repository.
I try code below in
babel-node
, andChrome Canary(v64)
, and get different result Unfortunately I could not understand what behavior is correct by this specIn this example I call
iterator.next()
twice, and synchronously 1) I expect thatpoint#2
andtask#2
will be called immediately(within seconditerator.next()
), because there is noawait
for thetask#1
I give this behavior atbabel-node
, but not inChrome Canary
Chrome executepoint#2
only whentask#1
resolved, like as I wroteyield await task('task#1')
insteadyield task('task#1')
2) Should thepromiseCapability/IteratorResult
be resolved only when theresult
is resolved, and contain resolved value? 2.1) Inbabel-node
IteratorResult
resolved, whenyield
got the value(pending Promise), and return this value without additional awaiting. In other word IteratorResult..value can be aPromise
2.2) InChrome
IteratorResult
resolved, whenyield
got the value(pending Promise), and this value also resolved. In other word IteratorResult..value cannot be aPromise
- it is always fulfilled valueI read "Async Generator Rewrite", and it turns out that the behavior of the
babel
is correct But when I read https://github.com/tc39/proposal-async-iteration/issues/114, I'm confusedWhat is correct behavior for this example?
babel-node execution log
Chrome Canary execution log