Skip to content

reflect: Elem() discards flagAddr #8321

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

Closed
gopherbot opened this issue Jul 2, 2014 · 2 comments
Closed

reflect: Elem() discards flagAddr #8321

gopherbot opened this issue Jul 2, 2014 · 2 comments

Comments

@gopherbot
Copy link
Contributor

by pronox:

What does 'go version' print?

go version go1.3 linux/amd64

What steps reproduce the problem?

1. Create a value with kind `Interface`, holding an addressable value
2. Reflect the container value using reflect.ValueOf
3. Query addressability of contained value

See http://play.golang.org/p/uM5mwL1zxW for running example.

What happened?
false returned

What should have happened instead?
true returned

Please provide any additional information below.

This originated from http://stackoverflow.com/questions/24471907.

The reason for this behaviour is that Value.Elem() fails to pass on flagAddr to the
newly created Value:
https://code.google.com/p/go/source/browse/src/pkg/reflect/value.go?name=go1.3#844
@ianlancetaylor
Copy link
Member

Comment 1:

This seems to me to be correct.  You have a []interface{}.  You can take the address of
element 0 and you can set element 0.  But what your program is trying to do is to take
the address of the value stored in the interface{} that is element 0, and that you can
not do.  There is no way to write Go code to do that.
Moreover, if you could do it, then you could, in different code, change the interface
value to hold different type, and then you would have a pointer to the interior of an
interface that was not the type of the value actually stored in the interface.  So if
this were permitted it would not be type safe.

Status changed to WorkingAsIntended.

@gopherbot
Copy link
Contributor Author

Comment 2 by pronox:

OK, when you put it that way it makes sense. I guess my intuition failed me on that
because reflection *knows* the underlying type so it is *possible* (but obviously not
implemented) to return a typed pointer to the underlying value of the interface{} value
which would prevent another type being put into the interface{} value. 
Since there is no equivalent Go code for this reflection feature it is unlikely to be
ever implemented. Thanks for the clarification.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants