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

proposal: Go2: automatically take address of pointer parameters (reference arg behavior) #33088

rcoreilly opened this issue Jul 12, 2019 · 2 comments


Copy link

commented Jul 12, 2019

[Apologies if this is a dupe -- couldn't find it.]

This proposal is to automatically take the pointer address (i.e., apply the & operator) of any non-pointer parameters that are passed to function arguments declared as pointers. This would make the behavior for the rest of the arguments consistent with the behavior for the receiver arg in a method.

When calling a method that is declared with a pointer receiver, the compiler automatically takes the address of a non-pointer variable.

Likewise, it would be more consistent, and convenient, if the compiler also automatically took the address of non-pointer parameters passed to pointer args. This would effectively mimic the behavior of the reference type from C++, without introducing any new syntax, and would not affect the ability to compile existing Go1 code as it is just turning what is currently an error into a valid function call.


func (r *MyType) MyFunc(oth *OtherType) {
    a := MyType{}
    b := OtherType{}
    a.MyFunc(b)  // compiled as: a.MyFunc(&b)

@gopherbot gopherbot added this to the Proposal milestone Jul 12, 2019

@gopherbot gopherbot added the Proposal label Jul 12, 2019


This comment has been minimized.

Copy link

commented Jul 12, 2019

The disadvantage is that normally when writing F(x), I know for sure that x does not change (of course, if x is a slice or map, some elements of x might change, but x itself will not change). It's true that the receiver behaves differently, but that is a case that Go programmers know to be aware of. Making this change will make it harder to understand what happens when reading Go code.

Speaking only for myself, I think this would be a bad idea. When I personally write C++ code, I use pointers, and I use const references, but I never use non-const references. There are existing C++ style guides, such as the Google style guide, that make the same choice ( (I work at Google but I don't write C++ at Google). So this suggestion is trying to bring in a feature from C++ that a significant number of C++ programmers intentionally avoid. Simpler to not bring it in in the first place.


This comment has been minimized.

Copy link

commented Jul 13, 2019

I understand and appreciate that perspective. However, just to push back a bit: given that Go does not have const, it is not possible to adopt that coding style. Adopting this change would actually enable greater semantic clarity about the arg usage (i.e., a "poor man's const"): use an explicit & for args that are modified, and don't add & for "const" non-modified args. Thus, the code reader could then easily tell which args are being modified and which are not. The code writer presumably knows the semantics of the function and can decorate accordingly.

This convention would obviously not be enforced by the compiler, but could be part of the standard style guide and enforced in code reviews etc.

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