Suggestion: use `yield.sent` instead of `function.sent`

[dead-claudia]

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).

[ljharb]

function.sent would also be helpful for arrow functions too, so it's not just generators - I think yield wouldn't be appropriate.

[dead-claudia]

@ljharb What would function.sent be with arrows?

[ljharb]

Hmm, maybe I'm thinking of something different. Rereading https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md does imply it's just for generators.

I was thinking of it like arguments for arrow functions.

[allenwb]

A complication is that yield in non-strict code and outside of a generator yield is just a normal non-reserved identifier that can used as a variable name. Hence is such contexts yield.sent is just a property reference. We can't change that for backwards compat reasons. In a strict mode code (including within generator functions) yield.sent is a syntax error because yield is an AssignmentExpression rather than a PrimaryExpression.

It's bad enough that yield means different things based upon the context. I think it would be making things worse to for yield.sent to have differing valid context dependent meanings.

[dead-claudia]

@allenwb Welp... 😦 Problem is, there's not really a lot of decent options...

Keep in mind, function.sent is generator-specific, so I was going from there, and my yield.sent was also meant to be generator-specific.

It's bad enough that yield means different things based upon the context. I think it would be making things worse to for yield.sent to have differing valid context dependent meanings.

Agreed, hence my reservations now. :-\

[claudepache]

It's bad enough that yield means different things based upon the context. I think it would be making things worse to for yield.sent to have differing valid context dependent meanings.

If we take the point of view that non-strict mode is supposed to be mostly a backward-compatibility mode, and that new code are encouraged (and even forced in some cases) to be strict, that concern about non-strict mode should be less important.

[lifaon74]

I see a great opportunity to use yield.sent yield.last instead of function.sent.

We could imagine something more generic like this:

function * it() {
  let i = 0;
  while (true) {
    i += yield.last; // get absolute last value sent with next()
    yield i; // we don't update *i* here
  }
}

const _it = it();
_it.next(1); // 1
_it.next(2); // 3

[dead-claudia]

Revisiting this, I feel yield.received would be better, since it's referring to the last received next parameter. yield.last, yield.sent, and function.sent all seem to imply the last yielded value, not the last received value.

[hax]

All names of yield.xxx suffer from the issues:

1. yield.xxx and (yield).xxx have different semantics in generators.
2. yield.xxx have different semantics in generators (meta property) and non-strict non-generator codes (normal property).
3. yield.xxx and yield xxx looks close if the font of . is too inconspicuous 😂
4. yield.xxx and yield*xxx looks close if the font of . is too conspicuous 🤣
5. yield.xxx implies something caused by yield but actually the main reason of this proposal is about the first sent value before any yield (or without any yield).

I feel no any single issue is fatal, but there are too many potential ambiguity so maybe we should first consider alternatives of function.xxx instead of yield.xxx.

[ljharb]

I don't think we have to worry about the font; anything can be unreadable with the wrong font.

Adding parens to things causes different semantics all over the place; i don't think that's a concern either - similarly, yield has a different semantic in generators vs non generators, so that's also not a concern.

However, your last point is compelling; it'd be great to find another alternative.

[hax]

Adding parens to things causes different semantics all over the place

@ljharb Could you explain more about that? I don't know other case which have different semantics between identifier.xxx with (identifier).xxx

it'd be great to find another alternative

Do you have any options? 😀

[ljharb]

• (a?.b).c vs a?.b.c
• a, b.c vs (a, b).c
• a + b + c vs (a + b) + c vs a + (b + c) when all three are different types
  etc

No suggestions yet.

[hax]

@ljharb What I mean is member access (or similar, like metaproperty) chaining 😅

• a, b.c vs (a, b).c
• a + b + c vs (a + b) + c vs a + (b + c)

So I don't think these two cases are comparable to yield.xxx vs (yield).xxx at all.

• (a?.b).c vs a?.b.c

Actually this case seems weird at first glance, and there were several issues and discussions about that. IMO yield.xxx vs (yield).xxx is even worse because: it seems no real use case of (a?.b).c, but (yield).xxx in generator has valid use cases.