I think that is my point. The methods in the code I shared have a proper receiver type based on the requirements of the methods. It only “breaks” in the context of the usage which isn’t at all obvious.
So it seems to me that go lint should at least complain that a struct has mutating methods so all methods should take pointer receivers. > On Jun 7, 2021, at 9:19 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > > FWIW I do tend to mix value and pointer receivers occasionally. > Sometimes a type needs a pointer receiver in one method, but a different > method doesn't and it's more convenient to have a copy available for > temporary operations. > Usually when I implement flag.Var, I make `Set` use a pointer receiver and > `String` use a value receiver - because why not? There is no pointer needed > to stringify a value. > Sometimes I have a slice type which should generally be used and passed as a > value, but for convenience, I add a `push`/`pop` method to it, with a pointer > receiver. > > Of course, all of these things *could* be accomplished by just using > pointer-receivers everywhere. But by that same logic, why have value > receivers anyway? You *could* always use a pointer. > > I don't think it's a huge problem to mix the two. It's true that this means > the pointer and the value type implement different interfaces - but I don't > think that's a huge problem either. I *definitely* doubt that it's "the most > inconsistent and obtuse aspect of the Go language". I'm not saying it *never* > caused any problems for me, but it definitely isn't as frequent a source of > bugs as the behavior of closures in loops, or slices unintentionally sharing > elements after append… All of which I'm fine with as well. > > But FTR, this discussion is definitely off-topic in this thread. And it's > also moot in general: It's not something we can realistically change now. > >> On Mon, Jun 7, 2021 at 3:05 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> There is no good reason that proper behavior should be dependent on >> understanding best practices. It should help with readability not >> correctness. Seems to me the compiler or Go Vet should prohibit this - in my >> review of the stdlib and other projects I can’t see any reason why it >> doesn’t. >> >>>> On Jun 6, 2021, at 11:10 AM, jake...@gmail.com <jake6...@gmail.com> wrote: >>>> >>> >>>> On Sunday, June 6, 2021 at 9:33:31 AM UTC-4 ren...@ix.netcom.com wrote: >>>> For example, the fact that this code is broken is not intuitively obvious >>>> for any reader. It requires way too much scrutiny IMO. >>>> >>>> https://play.golang.org/p/-f73t_Pm7ur >>> >>> I would like to note that your example goes against the general advice that >>> all methods should be on either pointers or values. Mixing value and >>> pointer methods for the same types is a code smell. The code you posted is >>> a good example of one of the reasons why. >>> >>> The second to last paragraph in the FAQ section >>> https://golang.org/doc/faq#methods_on_values_or_pointers says: >>> "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." >>> >>> In your example, if MyEventRecorder.Log() is changed to have a pointer >>> receiver, then the code works as expected: >>> https://play.golang.org/p/MG10opC6Ect >>> >>> -- >>> 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/a9b4a8b3-0b2f-4935-807e-1cbca03a3b20n%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/7C376006-EFA0-44BA-A036-B768078E4AA4%40ix.netcom.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/CAEkBMfGYRdadYFidvhCKnNqKDeqBSJLWBEU%3DuCJrxr1SbhPepQ%40mail.gmail.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/406A98CC-3D33-44A0-80E0-E40448DA3721%40ix.netcom.com.
