Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

[Victor Giordano]

You may forgive me.


El jue, 16 nov 2023 a las 11:57, Mike Schinkel ()
escribió:

> On Thursday, November 16, 2023 at 9:16:22 AM UTC-5 Victor Giordano wrote:
>
> Lads, I guess this entry  and the
> subsequent entries are very important regarding the discussion.
> *Also we shall recall that T and *T are different types. *
> *Golang performs some implicit conversions in order to make the code more
> readable when we use the methods "directly" on a concrete type, but when we
> use interfaces there is no implicit conversion.  I guess this entry
>  has key information about this affair.*
>
>
> For clarity, that was mentioned in this discussion, here
> .
>
> -Mike
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/Qb4IAEbpziU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/9f7c1d63-aa73-41a8-aeaf-1b191bec4cebn%40googlegroups.com
> 
> .
>


-- 
V

-- 
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/CAPUu9stOM8OO38wfd%3D%2B7_pU%2BVLpZi3xkQU5oVXadu2kN2bLnQg%40mail.gmail.com.

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

[Mike Schinkel]

On Thursday, November 16, 2023 at 9:16:22 AM UTC-5 Victor Giordano wrote:

Lads, I guess this entry  and the subsequent 
entries are very important regarding the discussion.
*Also we shall recall that T and *T are different types. *
*Golang performs some implicit conversions in order to make the code more 
readable when we use the methods "directly" on a concrete type, but when we 
use interfaces there is no implicit conversion.  I guess this entry 
 has key information about this affair.*


For clarity, that was mentioned in this discussion, here 
. 

-Mike

-- 
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/9f7c1d63-aa73-41a8-aeaf-1b191bec4cebn%40googlegroups.com.

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

[Victor Giordano]

Regarding the Original question:

I guess the advice of using a pointer receiver can be OK as long you know 
what you are coding.
quoting "https://go.dev/tour/methods/8;

> There are two reasons to use a pointer receiver.

> The first is so that the method can modify the value that its receiver 
points to.

> The second is to avoid copying the value on each method call. This can be 
more efficient if the receiver is a large struct, for example.
TD;DR;

Lads, I guess this entry  and the subsequent 
entries are very important regarding the discussion.
Also we shall recall that T and *T are different types. 
Golang performs some implicit conversions in order to make the code more 
readable when we use the methods "directly" on a concrete type, but when we 
use interfaces there is no implicit conversion.  I guess this entry 
 has key information about this affair.




El miércoles, 15 de noviembre de 2023 a las 17:34:02 UTC-3, Mike Schinkel 
escribió:

>
> On Nov 15, 2023, at 7:08 AM, 'Brian Candler' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> On Tuesday, 14 November 2023 at 03:38:04 UTC Mike Schinkel wrote:
>
> 1. A value variable and multiple value receivers  <--- compiles
> 2. A pointer variable and multiple value receivers <--- compiles
> 3. A pointer variable and multiple pointer receivers.  <--- compiles 
> 4. A value variable and multiple pointer receivers.  <--- will NOT compile
> 5. A pointer variable and mixed value+pointer receivers  <--- compiles 
> 6. A value variable and mixed value+pointer receivers. <--- will NOT 
> compile
>
> Permutation #4 and #6 are consistent with the description above, and they 
> both have *a value variable *in common.
>
> However, given than #5 DOES compile, I was left wondering why the standard 
> that mixed receivers should be flagged as an error? 
>
>
> I am not sure that "the standard" is for mixed receivers to be flagged as 
> an error. Can you give a specific example of where the standard Go 
> toolchain does this?
>
>
> Thanks for asking.
>
> In hindsight I was in-artful in my use of words. I should not have said 
> "flagged as an error" even though that is what GoLand does.  I should have 
> instead asked why the Go FAQ 
>  advised to use all 
> pointer receivers when there are any pointer receivers:
>
> *> Next is consistency. If some of the methods of the type must have 
> pointer receivers, the rest should too, so the method set is consistent 
> regardless of how the type is used. See the section on method sets 
>  for details.*
>
> BTW, I am assuming that GoLand flags mixed receivers as a concern because 
> of what the Go FAQ recommends.
>
> -Mike
>
> Is this question really about Goland, a third-party product, and/or some 
> underlying third-party linter that it uses?  If so, it's an issue for that 
> third party.
>
> Arguably it's not great style to do this, and it might make it confusing 
> for users of your package. But it's not an error, either for the compiler 
> or "go vet". https://go.dev/play/p/fBgrltIEjA2
>
>
> -- 
> 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/4fe6a954-696c-40f1-86cf-ea9148e42ba2n%40googlegroups.com
>  
> 
> .
>
>
>

-- 
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/554e15bd-227d-43ec-a61a-e0885fea4bc3n%40googlegroups.com.

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

[Mike Schinkel]

> On Nov 15, 2023, at 7:08 AM, 'Brian Candler' via golang-nuts 
>  wrote:
> 
> On Tuesday, 14 November 2023 at 03:38:04 UTC Mike Schinkel wrote:
> 1. A value variable and multiple value receivers  <--- compiles
> 2. A pointer variable and multiple value receivers <--- compiles
> 3. A pointer variable and multiple pointer receivers.  <--- compiles 
> 4. A value variable and multiple pointer receivers.  <--- will NOT compile
> 5. A pointer variable and mixed value+pointer receivers  <--- compiles 
> 6. A value variable and mixed value+pointer receivers. <--- will NOT compile
> 
> Permutation #4 and #6 are consistent with the description above, and they 
> both have a value variable in common.
> 
> However, given than #5 DOES compile, I was left wondering why the standard 
> that mixed receivers should be flagged as an error? 
> 
> I am not sure that "the standard" is for mixed receivers to be flagged as an 
> error. Can you give a specific example of where the standard Go toolchain 
> does this?

Thanks for asking.

In hindsight I was in-artful in my use of words. I should not have said 
"flagged as an error" even though that is what GoLand does.  I should have 
instead asked why the Go FAQ 
 advised to use all 
pointer receivers when there are any pointer receivers:

> Next is consistency. If some of the methods of the type must have pointer 
> receivers, the rest should too, so the method set is consistent regardless of 
> how the type is used. See the section on method sets 
>  for details.

BTW, I am assuming that GoLand flags mixed receivers as a concern because of 
what the Go FAQ recommends.

-Mike

> Is this question really about Goland, a third-party product, and/or some 
> underlying third-party linter that it uses?  If so, it's an issue for that 
> third party.
> 
> Arguably it's not great style to do this, and it might make it confusing for 
> users of your package. But it's not an error, either for the compiler or "go 
> vet". https://go.dev/play/p/fBgrltIEjA2
> 
> -- 
> 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/4fe6a954-696c-40f1-86cf-ea9148e42ba2n%40googlegroups.com
>  
> .

-- 
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/470BA5FB-72A9-4E00-A01C-CA8D4D9ED631%40newclarity.net.

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

[Vladimir Varankin]

> [..] when the method modifies the sruct's members (or just have a 
sync.Mutex member)

>From my experience, these are the major points for defaulting to use the 
pointer receiver "when in doubt". The difference between "func (t T) Foo" 
and "func (t *T) Foo", is often too subtle to spot a bug in a code change 
of a real production project. This is for sure, not the ultimate solution 
for human-errors. But it's pragmatic.

On Tuesday, November 14, 2023 at 6:37:27 AM UTC+1 Tamás Gulácsi wrote:

> I've always try to start with a value receiver,
> change to pointer receiver (EVERYWHERE - do not mix pointer and value 
> receivers!),
> when the method modifies the sruct's members (or just have a sync.Mutex 
> member),
> or used as interface (i.e. error  - for comparison to nil)
>
> Oliver Lowe a következőt írta (2023. november 14., kedd, 0:23:44 UTC+1):
>
>> > I'd be curious to hear thoughts on this topic. 
>>
>> There was a fun talk at GopherConAU just a few days ago: "What's 
>> The Point? A Guide To Using Pointers Without Panicking" (talk 
>> description at https://gophercon.com.au/) When the recordings are 
>> all finalised I can reply to this thread with a link. 
>>
>

-- 
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/38dea6ca-5dc8-4e78-b50d-ca10f00bbaabn%40googlegroups.com.

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

[Tamás Gulácsi]

I've always try to start with a value receiver,
change to pointer receiver (EVERYWHERE - do not mix pointer and value 
receivers!),
when the method modifies the sruct's members (or just have a sync.Mutex 
member),
or used as interface (i.e. error  - for comparison to nil)

Oliver Lowe a következőt írta (2023. november 14., kedd, 0:23:44 UTC+1):

> > I'd be curious to hear thoughts on this topic.
>
> There was a fun talk at GopherConAU just a few days ago: "What's
> The Point? A Guide To Using Pointers Without Panicking" (talk
> description at https://gophercon.com.au/) When the recordings are
> all finalised I can reply to this thread with a link.
>

-- 
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/c4bd392c-8561-4cde-89f0-677fde9ea241n%40googlegroups.com.

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

[Oliver Lowe]

> I'd be curious to hear thoughts on this topic.

There was a fun talk at GopherConAU just a few days ago: "What's
The Point? A Guide To Using Pointers Without Panicking" (talk
description at https://gophercon.com.au/) When the recordings are
all finalised I can reply to this thread with a link.

-- 
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/E0EA9600-7855-47B2-B359-3BD4BE75D969%40olowe.co.

[go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

['Brad Johnson' via golang-nuts]

Google's style guide is a popular reference for Go programmers. In it, they 
list off a number of scenarios where one would use a value receiver vs a 
pointer receiver. But, ultimately, they end the list with "when in doubt, 
use a pointer receiver".

In my experience, I've noticed the majority of Go programmers I encounter 
default to using pointer receivers in all circumstances. And I have a hard 
time justifying any protest because the scenarios typically don't fall into 
the "approved" set where value receivers are recommended.

I also notice that my IDE (GoLand) defaults to returning a pointer to a 
struct when I use its "Generate Constructor" auto-complete functionality. I 
can't help but suspect this was motivated by the "when in doubt" advice 
from Google.

I'd be curious to hear thoughts on this topic. I tend to advise developers 
to default to value receivers because I perceive benefits to avoiding nil 
pointer exceptions. But it's hard to substantiate my advice as anything 
idiomatic.

-- 
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/0f45d769-2f8d-49e3-85e4-3b2f46c8ac42n%40googlegroups.com.