Assignment of pointer values in a struct...

[Trig]

I posted this question the other day and don't see it (may have posted from another gmail account and it's still pending approval)... so here I am again.

Let's say I have something like below:

type (
   Person struct {
      FirstName *string
   }
)

Usually, I see something like the following when assigning:

fn := "John"
_ = Person{
  FirstName: &fn,
}

Would something like the following be alright and acceptable practice:

_ = Person{
  FirstName: pString("John")
}


func pString(content string) *string {
   return &content
}

[Ian Lance Taylor]

Sure, that's fine.

Ian

[Jake Montgomery]

Trig,

 I'm very curious why you want to use a pointer to a string? Since strings are immutable, and already are like "pointers" internally, I have rarely, if ever, used *string in go. What is it that you achieve by doing this?

- Jake

[Saksham Saxena]

Yep perfectly fine. MongoDB Driver for Go also uses such a wrapper at many places where it takes a string as an argument and returns a pointer to it which is required internally. Not really sure why use a pointer to strings in Go because they're immutable, but I guess to reach their own.

[Robert Engels]

You need pointers to strings if you need a nil value to be represented which is often the case in databases.

> On Jun 4, 2020, at 9:30 AM, Saksham Saxena <ont...@gmail.com> wrote:
>
> Yep perfectly fine. MongoDB Driver for Go also uses such a wrapper at many places where it takes a string as an argument and returns a pointer to it which is required internally. Not really sure why use a pointer to strings in Go because they're immutable, but I guess to reach their own.
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/17f2c250-ea5f-41fc-ac1b-0890a69f593b%40googlegroups.com.

[Trig]

And I did it again... posted from another gmail account by accident, and my post is forever in 'approval status', lol.  Basically what Robert here said.

On Thursday, June 4, 2020 at 9:53:56 AM UTC-5, Robert Engels wrote:

You need pointers to strings if you need a nil value to be represented which is often the case in databases.

> On Jun 4, 2020, at 9:30 AM, Saksham Saxena <ont...@gmail.com> wrote:
>
> Yep perfectly fine. MongoDB Driver for Go also uses such a wrapper at many places where it takes a string as an argument and returns a pointer to it which is required internally. Not really sure why use a pointer to strings in Go because they're immutable, but I guess to reach their own.
>
> --
> 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 golan...@googlegroups.com.

[Jan Mercl]

On Thu, Jun 4, 2020 at 5:13 PM Trig <edb...@gmail.com> wrote:
>
> And I did it again... posted from another gmail account by accident, and my post is forever in 'approval status', lol. Basically what Robert here said.
>
> On Thursday, June 4, 2020 at 9:53:56 AM UTC-5, Robert Engels wrote:
>>
>> You need pointers to strings if you need a nil value to be represented which is often the case in databases.

That's a very expensive way to represent a simple boolean value.

type String struct {
S string
Valid bool
}

is a value of the same size as a slice is, so passing it around has
the same cost with no additional allocations.

[eric....@iocentrics.com]

When you need to differentiate between nil and and empty string (because whatever you're assigning to, a "" may be valid).  For lack of time (and going into detail myself), here's a write-up on a reason why:  https://dhdersch.github.io/golang/2016/01/23/golang-when-to-use-string-pointers.html

Also, just mainly used *string as an example here.  Although I played with pprof and made sure the GC played with this properly, I just wanted to make sure I didn't overlook anything (causing memory leaks, etc.) and make sure it's 'acceptable practice' before I went that route.  To me, implementing lots of pointers in models for our APIs, it's easier for me to do this than declaring everything above in a variable when assigning.