think whether B.C should match A.B.C

[mvdan]

Right now it doesn't. A.B does match the beginning of A.B.C. This is because of the nature of how these trees of selectors are built - (A.B).C. It should be noted, however, that $x.C does match the entire A.B.C because of this.

Is there a use case for this? Haven't found a real one. Found this quirk while playing.

/cc @rogpeppe

[rogpeppe]

I think this is correct. I've never needed B.C to match A.B.C when writing gofmt -r expressions, and I think it's useful that it doesn't because I don't think I ever want io.Write to match something.io.Write, for example. In fact I've definitely relied on this property before.

Field names and method names are qualitatively different from expressions, and I don't think it's useful to maintain that distinction.

[mvdan]

Ah, good point. Idea shut down.

[mvdan]

I hear the point about sometimes not wanting B.C to match A.B.C. But I have just found one case that is the opposite.

I wanted to match all exec.Command("go", ...) call expressions. I tried:

gogrep 'exec.Command("go", $*_)'

Which works almost everywhere, except in the exec package itself - because there, we have just Command("go", ...).

Perhaps another way to go around this would be to match exec.Command by its definition (via type information) rather than AST matching. Then, if the user did import exec1 "os/exec" and exec1.Command("go", ...), it would match too.

[rogpeppe]

Yeah, that's an interesting point. It applies to type aliases too. For example we might do:

gogrep 'http.Request'

but that won't find places that it's mentioned via a type alias (which we probably want).
Maybe we could consider being able to add constraints for identity.

e.g. (straw man)

 gogrep -is x=exec.Command '$x("go", $*_)'