RFE: Provide a shortcut for taking the address of a literal

[satye...@gmail.com]

Greeting Gophers!

After using Go for a couple of medium sized products, I have come to realize that a lot of libraries use pointers to emulate optional/maybe types.This includes the protobuf auto generated code for Go. Since there is no direct way to take the address of a literal, people end up writing something like:

value1 := "A nice string!"
value2 := 64
library.Function(&value1, &value2)

Some libraries provide helper functions that look like:

func String(str string) *string {
 return &str
}

func Int64(num int64) *int64 {
 return &num
}

While both methods do the job, neither of them is elegant. In the first case, the developer is forced to declare throwaway variables, whereas in the second case, multiple libraries implement the same functionality. I personally ended up implementing a pointers library for use across my projects.

Is is possible to provide a standard shortcut for taking the address of a literal? Something like:

library.Function(&"A nice string!", &64)

or

library.Function(&string("A nice string!"), &int64(64))

will do the trick. Even a standard library implementation of the helper functions would be nice - though not as elegant.

I am aware that some discussions on this topic have taken place in the past, but all the threads I have found were 3+ years old. Now that the Go ecosystem has matured and we know what kind of libraries are being implemented, perhaps it is time to revisit this?

An alternative would be to provide a way to determine whether a variable has been initialized for non pointer types, but I guess that is too big a change to Go 1.x - even if it is accepted in the first place.

--

Thanks,

Satyen Rai

[Konstantin Khomoutov]

On Fri, 14 Oct 2016 07:04:37 -0700 (PDT)
satye...@gmail.com wrote:

[...]

> Is is possible to provide a standard shortcut for taking the address
> of a literal? Something like:

[...]

I think that if something like this is finally allowed, I'd instead
make a 2-arg form of new() possible to be able to do

library.Function(new(string, "A nice string!"), new(int, 64))

At least, this would not add more syntax than there alredy is.

[Dave Cheney]

I think you've selected the wrong hammer for your task. If you have a constructor function that takes a set of values which are usually not set (ie, you just want the default to be chosen for you), consider Rob Pike's Functional Options pattern. http://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

[Satyen Rai]

I am not trying to write an API that uses pointers to emulate optional/maybe types. I am trying to use pre-existing ones (which I have no control over) which expect pointers as arguments. Unless I missed something in the blog posts, I am not sure how Functional Options help with that.

Additionally, while Functional Options seem kind of neat once you have gotten the hang of them, they are not the first things that come to mind when one thinks about writing functions/methods with optional parameters. Given that optional parameters are a rather common pattern, don't you think there should be a simpler (more intuitive) solution supported at the language level?