Should we allow `function.sent` in arrow functions?

[hax]

We can refer other meta properties in arrow functions, for example:

function X() {
  return () => new.target
}
new X()() // X

Shall we also allow it for function.sent?

Possible usage: short alias for function.sent

function *numberToken() {
  const v = () => function.sent

  let sign = 1, integer = 0, fraction = 0
  if (v() === '-') {
    sign = -1
    yield
  } else if (v() === '+') {
    yield
  }
  while (v() >= '0' && v() <= '9') {
    integer *= 10
    integer += v().charCodeAt(0) - '0'.charCodeAt(0)
    yield
  }
  if (v() === '.') {
    yield
    let x = 1
    while (v() >= '0' && v() <= '9') {
      x *= 10
      fraction += (v().charCodeAt(0) - '0'.charCodeAt(0)) / x
      yield
    }
  }
  if (v() === undefined) return sign * (integer + fraction)
  throw new Error()
}

Problem: arrow functions are also "function" so programmers may expect they have own function.sent? And there will be generator arrow functions and they should have their own function.sent... (This is just again a naming issue like #1 (comment))

Alternative: make function.sent a function instead of a changing value so we can just write

const v = function.sent

(Another possibility is do not change anything, wait for refs proposal const ref v = ref function.sent)

[ljharb]

In your first example, i have no idea why that's a function rather than just a variable (const v = function.sent).

Generator arrows (if they ever manifest) would need their own function.sent, but it'd be possible for them to bind it while normal arrows would not (this does complicate the naming issue).

I'm very confused why it would need to be a function in any case.

[hax]

i have no idea why that's a function rather than just a variable (const v = function.sent).

Sorry I wrote a bad example, fixed now.

why it would need to be a function in any case

Currently we define function.sent as a value which will be auto updated after yield, so there is no simple way to alias it, u need manually re-assign after any possible yield.

PS. Make it a function also provide possibility of rich semantic, for example, it could have arg. See #3 (comment)

[ljharb]

sure, you could think of it as a getter on function.

I think those "richer semantics" would be very confusing. Requiring that you save it in a variable if you need it across yields seems reasonable to me.

[hax]

you could think of it as a getter on function.

Yeah, but it still not solve the "no simple way to alias it" problem. And if we think it as getter on function, it's no much difference to change it to method on function 😆