proposal-function.sent
proposal-function.sent copied to clipboard
tc39
Generator function.sent Meta Property
Hi, I would know where was this project ? I'm very interested in this specs as it would solve many problems js developers face with generator used as "data receiver"...
```ts function *g() { const x = yield 1 } ``` TS will say `"yield' expression implicitly results in an 'any' type because its containing generator lacks a return-type annotation.(7057)`....
My current — and potentially incorrect — understanding is that the proposed `LastYieldValue` component of _genContext_ is almost the same thing as the `received.[[Value]]` mentioned in - [**14.4.14 Runtime Semantics:...
if you want the first `.next(0.1)` to work with `yield`, you can just wrap the generator and just drop the first `.next` on the floor ```js const skipFirstYield = (generator)...
It IMHO explains itself a little better, and it looks more generator specific than `function.sent` (which looks like it would belong in any *function*, not just any generator).
The rationale for a proposal should do two things: - illustrate what the feature is for and what it's not for - make the case that that's worthy of language-level...
``` YieldExpression:yield*AssignmentExpression ... 4. Let received be NormalCompletion(undefined). ``` May it update to `4. Let received be NormalCompletion(LastYieldValue)` so we can satisfy: ``` js function *g1() { yield function.sent }...
We can refer other meta properties in arrow functions, for example: ```js function X() { return () => new.target } new X()() // X ``` Shall we also allow it...
This proposal in my mind seems to trying to work around an issue that shouldn't exist in the first place. Although there may be some small risk of backwards incompatibility,...
Hi, while implementing `function.sent` support in Babel I got a doubt: is this code valid? ```js function* foo() { function.sent; } ``` The current specification disallows it (an ExpressionStatement can't...
