Skip to content

reflect: add method to obtain function name #3901

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.

Sign up for GitHub

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

Jump to bottom
Closed
mxk opened this issue Aug 3, 2012 · 15 comments
Closed

reflect: add method to obtain function name #3901

mxk opened this issue Aug 3, 2012 · 15 comments
Labels
FrozenDueToAge

Comments

@mxk
Copy link

mxk commented Aug 3, 2012 

In reference to:

https://groups.google.com/d/topic/golang-nuts/DviFhNS0SbI/discussion

Example of what I was trying to accomplish:

http://play.golang.org/p/vyCgZZ8zBB

The proposal is to add a method to reflect.Value that would simplify the process of
retrieving the names of package-level functions. The assumption is that you already have
a reference to the function in question (i.e. the goal is not to "discover"
all functions in a package).

It might be useful to provide information about the package that the function belongs to
separately. The code in FuncName seems to work, but maybe there is a better way to do
the same thing.
@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 1:

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

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 2:

Labels changed: added go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 3:

Labels changed: added size-m.

@robpike
Copy link
Contributor

robpike commented Mar 7, 2013

Comment 4:

Labels changed: removed go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 5:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 6:

Labels changed: added feature.

@rsc
Copy link
Contributor

rsc commented Aug 3, 2013

Comment 7:

This seems easy in gc.
Ian, are there complications to worry about in gccgo?
It's really just a matter of calling runtime.FuncForPC, assuming that's implemented.

@ianlancetaylor
Copy link
Member

Comment 8:

gccgo has runtime.FuncForPC.  The results may not be what people expect, as for various
reasons there can be 1, 2, or even 3 variants of a function in gccgo, and they all get
different names.  The program above prints this with gccgo:
main f2$descriptorfn returned G
main f5$descriptorfn returned O
main f3$descriptorfn returned L
main f1$descriptorfn returned A
main f4$descriptorfn returned N
main f2$descriptorfn returned G
main $nested0$descriptorfn returned !
I could probably rationalize the names in some way, perhaps even in FuncForPC.

@rsc
Copy link
Contributor

rsc commented Aug 13, 2013

Comment 9:

I am not sure I want to add this to reflect. In general it may not be possible to give
the correct name, if two functions with identical bodies are merged into one symbol. I
think runtime.FuncForPC possibly giving back weird information in the face of
optimizations is much more defensible than reflect doing it. runtime is what it is, but
reflect should be 100% accurate.
If we do put this into reflect I think we'd be compelled to disable that kind of
optimization.

Labels changed: added go1.3maybe, removed go1.2maybe.

Status changed to Thinking.

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 10:

Labels changed: removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 11:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 12:

Labels changed: removed feature.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 13:

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

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 14:

Labels changed: added repo-main.

@ianlancetaylor
Copy link
Member

Comment 15:

Frankly I don't think we should do this.  Any implementation would either constrain the
compilers more than I think we ought, or in some cases return that the name is unknown. 
I think we need a more compelling use case to even consider the possibility.

Status changed to WontFix.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@rsc @ianlancetaylor @robpike @mxk @gopherbot