| 00:14 | <bakkot> | didn't we talk about this at some length? |
| 00:16 | <bakkot> | returning NormalCompletion is basically saying this is the "fall off the end of the function body without hitting a return" case |
| 00:16 | <bakkot> | returning ReturnCompletion is basically ending with an explicit return |
| 00:16 | <bakkot> | the latter is clearer |
| 00:17 | <bakkot> | the only reason we even support the NormalCompletion case in the machinery is to deal with implicit returns in syntactic generators, so it's weird to rely on it for non-syntactic generators which do not have implicit returns |
| 00:18 | <jmdyck> | 3457 changed one ReturnCompletion(*undefined*) to NormalCompletion(~unused~) |
| 00:19 | <bakkot> | that's not inside of an AC though |
| 00:21 | <bakkot> | I guess it is fair to say that we could have built-in generators match non-generators by never returning a return completion |
| 00:21 | <bakkot> | but the machinery which consumes those completions is pretty different so I'm not sure that symmetry makes sense |
| 00:24 | <bakkot> | in particular, the machinery which consumes completions for built-in functions (https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-built-in-function-objects-call-thisargument-argumentslist) is not the same as the machinery which consumes completions for ES functions (https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-ecmascript-function-objects-call-thisargument-argumentslist), whereas for generators it's the same machinery in either case (https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-generatorstart) |
| 00:40 | <Michael Ficarra> | alright, well leave your opinion on the PR then |
| 00:40 | <Michael Ficarra> | I've opened a few PRs related to completion records and ACs as discussed at editor call: https://github.com/tc39/ecma262/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+author%3Amichaelficarra |
| 00:54 | <bakkot> | hm so I think some of the generator stuff might be broken actually |
| 00:55 | <bakkot> | ah, wait, nevermind it's fine, just kind of weird |
| 00:56 | <bakkot> | GeneratorStart does Evaluation of a FunctionBody parse node, which I was thinking should be https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-runtime-semantics-evaluatefunctionbody but it's actually not |
| 00:57 | <bakkot> | it just falls through to Evaluation of the FunctionStatementList |
| 00:57 | <bakkot> | which is also how EvaluateFunctionBody works: https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-runtime-semantics-evaluatefunctionbody |
| 01:10 | <bakkot> | ok, so, we have four kinds of function: ordinary/async/generator/async+generator |
| 01:10 | <bakkot> | for each of these, we have to handle throw completions, return completions, and normal completions |
| 01:20 | <bakkot> | right now, evaluating any of them produces either a throw completion or a return completion. for ordinary functions this is handled by translating normal completions to the others explicitly return a return completion holding the promise (for async functions) or generator object (otherwise). Then [[Call]] handles the two cases (throw completion and return completion) explicitly https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-ecmascript-function-objects-call-thisargument-argumentslist. I am tempted to say that instead EvaluateFunctionBody should translate return completions into normal completions, so that evaluating the other bodies can return a normal completion. this is what the async generator machinery does, in AsyncGeneratorStart step 4.i https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-asyncgeneratorstart |
| 01:21 | <Michael Ficarra> | @bakkot here's your answer to the desired semantics for compound assignment https://github.com/tc39/test262/pull/4459/files#diff-02f5df894e79077a1cab224a19f7489864719a2fcf3e821674c4eaa06a099159 |
| 01:21 | <bakkot> | nice |