go: cmd/compile: improve compiler error on embedded structs
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.9.2
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
Linux amd64
What did you do?
package main
type Foo struct {
A string
}
type Bar struct {
Foo
}
func main() {
a := Bar{
A: "bar",
}
}
https://play.golang.org/p/6LDcycp9lPB
What did you expect to see?
An error like: "The field ‘A’ doesn’t exist in ‘Bar’ but is instead embedded in ‘Foo’
What did you see instead?
“unknown field ‘A’ in struct literal of type Bar”
The motivation for this is often you will see encode:
var b Bar
...
Bar.A
Unless you go and actually pull the struct definition (which often is unnecessary) you can’t tell that ‘A’ was embedded. If you try to create your own Bar then you get the error above, which is confusing since it’s the same as if you misspelled the field name, or just got something wrong.
It’s not hard to scan any embedded structs and see if there is a matching field. It’s still legit to give an error, but you could definitely reduce confusion by having a better one.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 22 (18 by maintainers)
even if it is more precise, I don’t think that using the word ‘promoted’ will help with understandability.
I’ve been programming Go for > 4 years, and I’ve never heard of ‘promoted’ until today.
I’d recommend favoring understandability over precision here.
@mdempsky Error message suggestion (for your specific case): “cannot set embedded field C.B.A.a directly in composite literal C”.
I’d like to have a look at this if no one else is working on it.
Let’s not bike-shed the actual choice of words here. We can fine-tune the message in an actual CL. The direction seems clear: If the code indeed attempts to assign to a promoted field, the error message should probably mention the explicit path to that field (e.g.,
B.A.a).On second thought, I agree with the point that using “embedded field” will make everything more confusing in the long run. I can’t come up with a reasonably sized error message that would make the meaning of “promoted field” more obvious, so I take that back.
Thanks for that data point and input.
I think using a more precise, even if less common, term aids accessibility. As pointed out, searching the Go spec for “promoted field” explains what it means. Google searches for “golang promoted field” also turn up accessible explanations about embedding and promotion. Over time, I’d expect “promoted field” to become more commonly understood because of its use in this error message, and search results to be more helpful to new users in how to fix the error.
Also, I think today’s users who may be unfamiliar with the term “promoted field” will still understand the rest of the error. I think that’s better than using an incorrect term like “embedded field” which will increase misunderstanding.
/cc @mdempsky @griesemer @odeke-em