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 <https://go.dev/tour/methods/6> 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 <https://go.dev/tour/methods/9> 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 > <https://go.dev/doc/faq#methods_on_values_or_pointers> 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 > <https://go.dev/doc/faq#different_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 > > <https://groups.google.com/d/msgid/golang-nuts/4fe6a954-696c-40f1-86cf-ea9148e42ba2n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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.
