[RFC] Implement block expressions #5403
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@nikic
This implementation replaces the statement list (
'{' inner_statement_list '}'
) by a block expression that CAN contain an expression. After implementing it this way I don't think it's the right approach.Two things to note:
The reason for this is that the semicolon is optional with expression statements that only contain a single block expression to maintain backwards compatibility. Additionally the semicolon won't be enforced here:
Alternative approach
Instead of replacing the statement list completely we add the new block expression as
'{' inner_statement_list expr '}'
. This avoids the ambiguity with the existing statement list.To support blocks in arrow functions without returning a value we accept statement lists in the arrow functions body and transform it to a block with a null return value (
{ ...; null }
). This would solve the two cases above and require much fewer changes in the grammar.WDYT?
I'll create a PR for this alternative approach to demonstrate what I mean. The whole terminology here can be very confusing.
Side note: This breaks the optimizer in the same way the throw expression does (see 005.phpt).