Skip to content
This repository has been archived by the owner on Jun 9, 2021. It is now read-only.

decide whether "b; c" should match "{ a; b; c; d }" #20

Closed
mvdan opened this issue Sep 23, 2017 · 4 comments
Closed

decide whether "b; c" should match "{ a; b; c; d }" #20

mvdan opened this issue Sep 23, 2017 · 4 comments
Assignees

Comments

@mvdan
Copy link
Owner

mvdan commented Sep 23, 2017

Reasons to:

  • Useful. I just needed it right now.
  • 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.
@rogpeppe
Copy link
Collaborator

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.

@mvdan
Copy link
Owner Author

mvdan commented Sep 25, 2017

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.

@mvdan
Copy link
Owner Author

mvdan commented Sep 25, 2017

The implicit blocks section on the spec: https://golang.org/ref/spec#Blocks

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.

@mvdan
Copy link
Owner Author

mvdan commented Oct 6, 2017

Blocks can now be matched aggressively: 1af77ee

So I'll get to this now.

@mvdan mvdan self-assigned this Oct 6, 2017
@mvdan mvdan closed this as completed in 0f4ecab Oct 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants