Domenic Denicola wrote:
I believe the argument is that you'd want `await a + b` to be `(await a) + b`, whereas with `yield` it's `yield (a + b)`.
We need a debugged grammar for await, when ready. We have one for yield (existence proofs in several browsers now), and I think we can fix ClassHeritage easily.
The reason why yield is low-precedence, at AssignmentExpression level, is to make the observed common case of yield a + b meaning yield (a + b). Python follows the same design, but the design comes from use-case frequency, not directly Python authority.
C# 5.0 (http://www.microsoft.com/en-us/download/dlx/thankyou.aspx?id=7029) makes await expression both a statement-expression (the entirety up to the ; terminator of a statement-expresion) and a unary-expression (which cannot be a statement-expression in C# -- but can in JS).
If we are copying C#, we can use a lookahead restriction as usual to handle the statement-expression vs. unary-expression cases. We can thus make async a unary prefix operator.
You may object: why have the two operators at such different precedence levels. It's a good question, but if we are going by precedent from two different languages, then the answer may be "because Blub did it that way".
Before we settle for that hash of a design, I'd like to know why C# put async at unary precedence. Maybe Luke knows, or can find out.
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
