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.
On Thursday, June 4, 2020 at 9:11:12 AM UTC-5, Jake Montgomery wrote:
>
> 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
>
> On Wednesday, June 3, 2020 at 10:33:31 PM UTC-4, Trig wrote:
>>
>> 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
>> }
>>
>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/ba77aff5-3a7a-43d0-b3bf-480c19efd576%40googlegroups.com.
