(I think you pasted the wrong link - that is my code). It is not about being unwilling to admit it. Your explanation/reasoning has not convinced me.
Imagine some library declares the EventLogger interface as shown. Acceptable. Someone writes the RecordEvents() method taking an EventLogger. Acceptable. Now, I have a struct I want to use with as an EventLogger (badly named - really EventSource). The code I wrote works fine. Test cases (of Log()) work fine. It fails when used as a source to RecordEvents() (and similar held reference patterns). How do you protect against this? What is the mechanism as a library author? Clearly this is a trivial example but similar patterns are everywhere. Compare the Go interface handling with Java’s everything is a reference - much simpler - and then adding value types that are explicit. Or a similar implementation in Rust. In both cases knowing you wrote a correct implementation is much easier. Java has since added annotations for aspects like “thread safe” that cover the atomic aspects. I like Go. A lot. I’ve designed and built systems with millions of LOC. Pointing out aspects that might benefit from changes should be encouraged - if not it’s a religion not a programming language. > On Jun 7, 2021, at 7:40 PM, Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > > >> On Tue, Jun 8, 2021 at 2:05 AM Robert Engels <reng...@ix.netcom.com> wrote: >> >> We agree. It needs a pointer receiver to work. The atomic is also needed in >> this case for background logging. >> >> The problem in this case is that recordEvents() has to document that the >> EventLogger passed to recordEvents() must have a pointer receiver for the >> Log() method. There is nothing in the language that allows me to declare it >> nor the compiler to enforce it. > > It is possible to write a working implementation of that interface without a > pointer receiver - it just needs to *contain* a pointer: > https://play.golang.org/p/Xm6ASGcCyhR > You could also have a slice type, which also can do modifications without a > pointer receiver. Or a map-type. Or a channel. > > If you would restrict an interface to require pointer-receiver, you would > wrongly restrict the implementer from all these possibilities. > > As is the common wisdom, the user of an interface should not care what the > concrete type implementing an interface is (except if it needs to do a > type-assertions). It's the same wisdom that applies to people wanting to > check if an interface contains a nil-pointer: That check relies on the > assumption that the interface contains a pointer, which shouldn't be nil and > that's not something that should concern the user of an interface. > > Again, to be abundantly clear (you still seem unwilling to acknowledge this): > The problem with your code is not the definition or usage of the interface. > It's the definition of the method that is wrong. The interface-definition is > fine and works fine. > >> If you don’t see this as suboptimal and an area for improvement I am not >> sure what else I can say. > > I just want to state again, clearly, that all I objected to was you calling > this "the most inconsistent and obtuse aspect of the Go language", which I > perceived (and still do) to be an overstatement. "It is suboptimal" or "it is > an area of improvement" are both significantly weaker statements, which I > find less objectionable. > > Personally, I still don't think it is a huge problem. And the fact that you > where having a lot of trouble coming up with an example showing it to be one > (the one you posted doesn't - again, it doesn't, in any way, change behavior > when using or not using interfaces) is, in my view, a testament to that. > >> And by the way, linters often flag correct code - that is why they have >> disable options. They try to enforce the most common cases - and by the >> recommendation in the faq to only use receivers of the same type - it seems >> appropriate to me to have the linter flag this. > > I'm opposed to a linter flag, because it would flag correct code I regularly > write. In general, linters should not be ignored - they either shouldn't be > run, or they should be followed. Note that golint has no option to > selectively disable a particular instance of a warning - the only way to > silence a warning is to change the code. But I don't want to use a pointer > receiver, if a value receiver is more appropriate. > > If golint or go vet would start flagging this, I would likely follow the > advice it's giving. Because that's how linters and static checks are supposed > to be used - to enforce consistency. But I'd be sad doing it. Which is why I > don't want them to flag it. > > I'm less opposed to the FAQ entry. Simpy because an FAQ entry can be more > easily ignored where it makes sense. If you will, it is one step in > stringency below a linter. I'm fine defending my choice in a code review, but > I don't want to defend it to a linter. > >> As to this being in my opinion the most inconsistent and obtuse aspect of Go >> - that is my opinion. Curious, what do you think would take the top spot? > > I'm not sure. I don't like putting things in absolute order or claiming > something is "the most X" for exactly that reason - it almost always turns > out to be an overstatement. > > Empirically, the issue of nil-pointers in interfaces not being nil seems to > take one of the top spots, even though I don't fully understand why. > To me, concurrency in Go is extremely subtle and I would generally advice > novices to stay away from it at first (or stay with extremely simple > constructs), because they are likely to get it wrong. > Details of how Go handles constants and type-identity/assignabiity is what is > probably most often tripping me, personally, up in questions/quizzes about > Go. But it rarely comes up in practice. > The lack of co/contravariance is probably one of the things I miss the most > from the language. > > It really depends on what you're asking. And I'm very likely forgetting > things while being put on the spot. > It's just a lot easier to make relative judgments, than absolute ones. > >> >> >>>> On Jun 7, 2021, at 6:34 PM, Axel Wagner <axel.wagner...@googlemail.com> >>>> wrote: >>>> >>> >>>> On Tue, Jun 8, 2021 at 1:26 AM Robert Engels <reng...@ix.netcom.com> wrote: >>> >>>> The pattern of a background stats collector is a common one. The atomic is >>>> required not optional. >>> >>> It might be a common pattern, but it uses a pointer-receiver in that case. >>> The atomic operation is not required, it operates on a local variable. >>> Again, I don't understand how you can make statements that are so clearly >>> wrong. >>> >>> Feel free to try running it in the race detector without an atomic >>> operation. Feel free trying to get the race detector to trigger without the >>> atomic access, but keeping it silent when you add it. You'll find that this >>> needs a pointer receiver. Because otherwise the function is operating on a >>> local variable. >>> >>>> >>>>>> On Jun 7, 2021, at 6:16 PM, 'Axel Wagner' via golang-nuts >>>>>> <golang-nuts@googlegroups.com> wrote: >>>>>> >>>>> >>>>> BTW, just to nail down the point of that code being wrong without >>>>> interfaces: Your usage of `atomic` in `Log` is superfluous. You are >>>>> operating on a local variable, so there is no possibility of concurrent >>>>> modification. Your code is equivalent to this: >>>>> https://play.golang.org/p/zYG0zTsk-2a >>>>> The only reason to use `atomic` here (and why you used it) is if that >>>>> memory could be shared between goroutines. For that to happen, you need a >>>>> pointer receiver though. >>>>> >>>>> I refuse to believe that interfaces have anything to do with this >>>>> obfuscation here. There is more than enough indication of it being wrong >>>>> in any case. >>>>> >>>>>> On Tue, Jun 8, 2021 at 1:05 AM Axel Wagner >>>>>> <axel.wagner...@googlemail.com> wrote: >>>>>>> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels <reng...@ix.netcom.com> >>>>>>> wrote: >>>>>> >>>>>>> I don’t think that represents the problem fairly. In the non interface >>>>>>> case I know I can’t accept a copy so I would declare the method as >>>>>>> taking a pointer to the struct. >>>>>> >>>>>> How methods are declared should, in general, not be a matter of whether >>>>>> or not they are assigned to an interface, but to whether or not they >>>>>> need a pointer. Again: Your code is incorrect without interfaces. The >>>>>> problem doesn't happen when you put that value into an interface - it >>>>>> happens when you pass a copy of it and expect it to refer to the >>>>>> original. Interfaces are just one way to create such a copy, but they do >>>>>> not matter for the correctness of this code and for whether or not that >>>>>> method needs a pointer receiver (it does). >>>>>> >>>>>> But again, to be clear: I'm not saying problems like this *never* happen >>>>>> and I'm not even saying that interfaces may obscure it in some cases. >>>>>> Just that a) the root cause here is that your method really needs to >>>>>> take a pointer-receiver, interfaces or not and b) that it seems very >>>>>> much an overstatement to me to call this "the most inconsistent and >>>>>> obtuse aspect of the Go language". >>>>>> >>>>>>> With interfaces this is lost - as the interface is implicitly a pointer >>>>>> >>>>>> Well, it seems a bad idea to say that interfaces are implicitly pointers >>>>>> then. That seems to indicate that Rob's original phrasing is indeed an >>>>>> important clarification - the language behaves as if the value contained >>>>>> in them is copied when the interface value is copied. >>>>>> >>>>>> It seems the confusion here is, that you assume it's not. And that >>>>>> interfaces act as a pointers, when they don't. >>>>> >>>>> -- >>>>> 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/CAEkBMfGVyvYYpQhCp_JkxN9EvgZ4FXJ8_WpxseJOB1OR7qt6ww%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/CAEkBMfHibUpDHQU9m8%3DrLYtnDj%3DFY01nkuP4k0Giow-hCbhNgQ%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/7AC630B6-05FA-4374-9B4B-3151886160D7%40ix.netcom.com.
