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?

On Saturday, 15 October 2016 00:53:30 UTC+5:30, Dave Cheney wrote:
>
> 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.

Reply via email to