You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 9, 2021. It is now read-only.
Using $*_; b; c; $*_ is not as useful, as it also prints the stuff on the sides.
Reasons not to:
If we really want a statement list with just b; c, there wouldn't be another way to express that. { b; c } does not cover it, as it wouldn't match statement lists outside block statements such as switch case bodies.
The text was updated successfully, but these errors were encountered:
I think that statements are a bit different from expressions in this respect. That is, I think it probably should match, because a sequence of statements are logically just a sequence rather than a hierarchy.
I can't currently think of a use case for requiring a statement list with just b; c.
If we changed this, I would like to change it consistently for all lists of nodes. I noticed your point about expressions, but I'm not sure if I agree, and I'm defaulting on consistency.
Perhaps one way around this would be for { b; c } to match case foo: b; c;. In other words, treat source code almost as if case expr: stmt-list was case expr: { stmt-list; }. That way, b; c would match any list with that sub-list, and { b; c } would match any list exactly equal to that list.
This would also apply to all other implicit blocks, as defined in the spec.
The only disadvantage I can think of is when one really wanted an explicit block, but not an implicit one. Like when one wants to convert an explicit case foo: { b; c } to case foo: b; c. Perhaps this should be done as part of #4, i.e. only match real blocks with implicit blocks in the aggressive mode.
Also, I completely contradicted myself in the last comment. My solution concerns statements, not expressions. So it would treat them differently, as you said.
Perhaps it's a good idea to start with this, and we can revisit other node type sub-lists if we find a use for those.
Reasons to:
$*_; b; c; $*_
is not as useful, as it also prints the stuff on the sides.Reasons not to:
b; c
, there wouldn't be another way to express that.{ b; c }
does not cover it, as it wouldn't match statement lists outside block statements such as switch case bodies.The text was updated successfully, but these errors were encountered: