I think the playground code I supplied is essentially a test case - and it works in the absence of concurrency or other held references (like putting it in a map).
I guess the bottom line for me is that faq says do not mix receiver types. There is either a valid reason for this or it should be removed. I think it is the former as it makes more usage patterns resilient to hard to track bugs. I must be very dense but I still don’t see the rationale behind not stating : use value receivers for immutable types and pointer receivers otherwise. There may be some fringe cases where this doesn’t hold - but if you can write the entire stdlib with this pattern it seems fairly stable. > On Jun 8, 2021, at 5:03 PM, 'Dan Kortschak' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > On Tue, 2021-06-08 at 07:57 -0500, robert engels wrote: >> The following code is works fine from the developers perspective: >> >> https://play.golang.org/p/gC1XsSLvovM >> >> The developer says, oh cool, I see this great new 3P library that >> does background logging - I want to use that instead. Hey, I already >> implement the EventLogger interface, so no problem, I take out my >> manual logging code, and make a call to recordEvents(EventLogger). >> >> Hmm, my program isn’t logging properly any more. Oh, it says >> background logging - that likely means concurrency - so maybe I have >> a race condition, so I run it under —race. Hmmm, says it's fine and >> it still isn’t working. :( >> >> Eventually the developer figures out that the call to recordEvents() >> is making a copy, and so needs pointer receiver and to create a >> pointer based interface reference (and add the atomic calls). It’s >> not clear to me how the library author would document things to avoid >> this scenario. >> >> If you don’t see that the above is suboptimal and an AFI I am not >> sure what else I can say. That a person of your caliber writes code >> that differs from the recommendation in the FAQ (the mixing of >> receiver types) is a flag to me that one of the approaches is >> probably not correct. >> >> ‘go vet’ already has the ability to disable certain checks. Adding a >> check to ‘go vet’ to detect mixed receiver types (which the FAQ says >> is not recommended) seems reasonable and will make life easier for >> many beginner Go programmers - and some seasoned ones as well :) >> >> The duplicitous and transparent nature of pointer/value receivers and >> interfaces is a source of confusion. I think being explicit would >> have been a better choice here but that horse has left the barn. > > > An error like this would be found in any reasonable set of tests for > the type. Minimally, if the type is intended to be passed to functions > in order to be able to be used, a test would involve that and that > would immediately surface the error. > > What you seem to be asking for is a way for the language to enforce > contracts on behaviour from the source and you seem to put that at the > feet of interface handling. However, it is clearly something that > arises without needing interfaces in the language; a user of the > MyEventRecorder type would already find problems if they pass the value > to a function without needing to do that in an interface value. Without > significant addition of annotations for implementations it is not > possible for the language to understand the contractual obligations of > an implementation, and these kinds of annotations are in opposition to > the design of the language. Other languages do have these kinds of > marks, but they are not Go (thankfully). > > In terms of documentation of expectations of an interface if that were > the situation, there are examples in the standard library where it's > described that implementations must be able to mutate themselves — be a > pointer receiver (or other reference-like type). > > > -- > 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/cce7af413d7cb56b4fd653703f1d49d6f5f7e7c6.camel%40kortschak.io. -- 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/578FCA64-1551-4902-B09F-2269A286C32D%40ix.netcom.com.
