Alex Russell wrote:
The issue with 'await' is: apart from sequence vs. mapping, given
that arrows have a limited Tennent's Correspondence Principle for
not only |this| and |super|, is it confusing to have |arguments|,
|yield|, and |await| not mean outer "bindings", vs. inner?
No.
So "No" to all? You want |arguments| and |yield| in arrow functions
working on the immediately enclosing arrow?
Whatever the |await| answer, we need a systematic approach or rule of
thumb for the other forms.
This line of reasoning only applies to async arrows, and not
to async function declarations, expressions, or methods.
Again, arrows are by nature syntax-light and tolerate a
higher degree of "inference" than other forms.
My point is that we should reserve "await" within arrows to
preserve these design options down the road. It can always be
unreserved later.
I think you have a point, whether we make |await| work or ban it
to avoid partial-TCP confusion.
I'll continue to point out that the confusion is largely a product of
language lawyering, not real-world expectations of JS behavior.
Banning await here is only a solution if you're also not going to ban
an async descriptor on the arrow expression. THAT is the mistake.
Lawyer Alex, esq, could you please answer the question of what
|arguments| in an arrow should do? |yield| in an arrow?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
