Open hax opened 4 years ago
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 https://github.com/tc39/proposal-function.sent/issues/3#issuecomment-625913301
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
😆
We can refer other meta properties in arrow functions, for example:
Shall we also allow it for
function.sent
?Possible usage: short alias for
function.sent
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 ownfunction.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(Another possibility is do not change anything, wait for refs proposal
const ref v = ref function.sent
)