On 13/09/2011 9:11 AM, Marijn Haverbeke wrote:
B) Limiting implied-semicolons-after-blocks to blocks that end with a
trailing semicolon, requiring blocks in loops (where the value is
discarded anyway) to end in a trailing semicolon, and always treating
blocks that do end in semicolons as the end of the expression.
Right now, you can say 'while true { 1 }' and starting a line after a
trailing-block expression (say 'if x { a(); } else { b(); }') with a
'(' or a '[' will cause the parser to think you're trying to call or
index the result of the if expression.
This one is ... a confusing set of rules. I take it empty loops have an
implied trailing semi in their body? That is: "while true {}"? I know
it's a degenerate case, just trying to clarify.
It seems to me a lot of look-behind / look-inside for a parser to be
doing, in order to disambiguate. Might it be easier to say that *all*
the ends-in-a-}-expressions represent the end of their enclosing
expression? That is, don't parse postfix or binary ops immediately after
a }, at all?
This would mean
'if foo { a } else { b } - 10'
would parse as 2 expr-stmts, the second one being "-10", and
must be written the following way to get its binop-meaning:
'(if foo { a } else { b }) - 10'
that doesn't seem a *huge* penalty to me, and is possibly closer to user
intuitions about control-flow braces anyways.
Note that some of this muddle might go away if we remove general
expr-stmts (as mentioned in footnote of previous email) and went with
separate res stmts to "get a value from a block". Though we'd probably
need to leave some special cases in for leading-lval forms such as
"foo();" or "foo = bar;". Hrm hrm.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
