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

Comments

@griesemer
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 1:

Labels changed: added go1.2.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 2:

Labels changed: added feature.

@dsymonds

This comment has been minimized.

Copy link
Member

commented Aug 14, 2013

Comment 3:

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

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2013

Comment 4:

Not for 1.2.

Labels changed: removed go1.2.

@davidthomas426

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 6:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 7:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 8:

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 9:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed priority-soon labels Apr 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.