Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reflect: field lookup ignores methods that cancel fields (ambiguity is ignored) #5706

Open
griesemer opened this issue Jun 14, 2013 · 9 comments
Open
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 14, 2013

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.
@rsc
Copy link
Contributor

@rsc rsc commented Jul 30, 2013

Comment 1:

Labels changed: added go1.2.

@rsc
Copy link
Contributor

@rsc rsc commented Jul 30, 2013

Comment 2:

Labels changed: added feature.

@dsymonds
Copy link
Contributor

@dsymonds dsymonds commented Aug 14, 2013

Comment 3:

Labels changed: added priority-soon, removed priority-triage.

@robpike
Copy link
Contributor

@robpike robpike commented Aug 30, 2013

Comment 4:

Not for 1.2.

Labels changed: removed go1.2.

@davidthomas426
Copy link
Contributor

@davidthomas426 davidthomas426 commented Oct 14, 2013

Comment 5:

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.

@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 6:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 7:

Labels changed: removed feature.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 8:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 9:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants