@mvdan Yes, we probably want to be as consistent as possible. In the early days we used both terms; more recently we have started talking about 'embedded' fields because even though they are embedded they still have a name (the type name) and thus are not anonymous in the strict sense.

That said, note that ast.Fields are also used for parameters which indeed may be anonymous. So we want to be a little bit judicious before making unilateral changes throughout.

But feel free to send me CLs.

That said, note that ast.Fields are also used for parameters which indeed may be anonymous. So we want to be a little bit judicious before making unilateral changes throughout.

I'm not sure I understand; could you please give an example of a field that is embedded and anonymous, and an example of a field that is embedded but not anonymous?

A Field is part of a FieldList. A FieldList is also used for function signatures (FuncType). Function parameters may be indeed anonymous and then Names may (will) be nil. In that case it makes sense to talk about anonymity (anonymous parameter). Fields are either embedded (originally called anonymous) or not.

In short, simply replacing "anonymous" with "embedded" everywhere will be confusing, too (there are no embedded parameters). When making those changes, the comments may need to be adjusted. That's all I'm saying.

Ah, I understand now - thanks for the clarification. Would you prefer a few CLs grouping changes, or one single CL to clarify these?

Depends on how many and where the fixes are. Use good judgement.

Change https://golang.org/cl/120556 mentions this issue: ast: refer to "embedded" rather than "anonymous" fields in

Note that this issue was meant to track the inconsistencies across the entire repository, not just this occurrence in go/ast. As you can see in the numbers above, there are more than thirty other cases that should be checked, so I'd leave this issue open unless we are sure that all the others are correct.

Reopening per @mvdan 's comment.