reflect: field lookup ignores methods that cancel fields (ambiguity is ignored) #5706
Milestone
Comments
We should not expect getting true for the second return value of FieldByName to imply that s.m will compile in the example above. There are other reasons we might not be able to SEE a field, even if it exists (e.g., it is unexported in a different package). The real problem, I think, is the comment at http://golang.org/src/pkg/reflect/type.go?#L860 that says "This uses the same condition that the Go language does", because it is not even close to true. I don't think people even want that to be true, unless they don't want to be able to use reflection to examine unexported fields of struct types from other packages. This is related to https://golang.org/issue/4876 as well, which has been marked fixed simply because the confusing behavior is now documented (by a comment in the code starting with "BUG", I might add). The real problem is that we don't seem to be sure whether we want reflection to show us all the internals or just the stuff we can get at. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1) $ cat x.go package main import "reflect" type S1 struct { m int } type S2 struct{} func (S2) m() int { return 0 } type S struct { S1 S2 } func main() { var s S t := reflect.TypeOf(s) if f, ok := t.FieldByName("m"); ok { println("field found:", f.Name) } else { println("field not found") } } 2) $ go run x.go field found: m But in truth, the field m and the method m are at the same level and thus "cancel each other out". In the same program, accessing s.m leads to a compile-time error ( ambiguous selector s.m ). The bug is in http://golang.org/src/pkg/reflect/type.go?#L856 (structType.FieldByNameFunc) which ignores methods.The text was updated successfully, but these errors were encountered: