Hi Rowan > Then why not introduce the match expression first, and add block > expressions (as a general concept) later?
Mainly because I fear it won't pass and we'll end up with a handicapped match expression that can't be used half the time. > That way, we don't need all the special restrictions on when to use them I think that's a little overblown. We're talking about ~5 lines here. > the code above *is* ambiguous Whether or not some code is ambiguous depends on the grammar that defines how it's interpreted. "1 + 2 * 3" can be ambiguous if the precedence isn't clearly defined. Bison will check that your grammar is unambiguous, otherwise you'll get a shift/reduce or reduce/reduce error (as in there's multiple ways to parse your code). The suggested grammar defines that the semicolon can be dropped under exactly one circumstance: When the match is the first and thus only element of an expression statement. This is what Rust does too. This clearly needs to be described better in the RFC. > The only downside is that omitting the parentheses wouldn't be an error, > as with the closure case, it would just silently do nothing, which might > be rather confusing. That is true. Since array subscripts and function calls don't allow arbitrary lhs expressions the code wouldn't work without parentheses but at least you'd get a parser error. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
