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
On Friday, 14 October 2016 18:15:16 UTC+2, Satyen Rai wrote: > > 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 > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.