Should we allow `function.sent` in arrow functions?
hax opened this issue · 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 #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
)
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.
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)
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.
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
😆