proposal-function.sent icon indicating copy to clipboard operation
proposal-function.sent copied to clipboard

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

Open hax opened this issue 5 years ago • 4 comments

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 https://github.com/tc39/proposal-function.sent/issues/1#issuecomment-528962680)

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)

hax avatar May 07 '20 14:05 hax

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.

ljharb avatar May 07 '20 17:05 ljharb

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 https://github.com/tc39/proposal-function.sent/issues/3#issuecomment-625913301

hax avatar May 08 '20 16:05 hax

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.

ljharb avatar May 08 '20 18:05 ljharb

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 😆

hax avatar May 08 '20 18:05 hax