No, the question is actually, why methods bound to *different* pointers, still print the same: https://play.golang.org/p/o2lgZBBYx- The same can be observed for closures (unsurprisingly): https://play.golang.org/p/B6QKQWiraL
I don't yet have a conclusive, detailed answer (I tried diving into the code, but didn't find the right place), but the pointer that is passed around isn't actually the pointer that is printed. You can see that in this code, which unsafely casts a func() to an unsafe.Pointer: https://play.golang.org/p/xmMm--Wxt3 As you can see, different closures are passed as different actual pointers in f. But fmt still prints them the same. It seems to unpack the actual pointer to the code from the closure-struct (or rather, reflect is doing that for fmt) for printing - which makes sense, if you are trying to debug, I guess. And the value itself doesn't really have semantic meaning anyway (as functions are not comparable). When calling the function literal, the compiler will then generate code to a) dereference the pointer to the closure struct, b) unpack the arguments from it and push them to the stack and c) call the function pointer contained in the struct. You can also see this effect, when compiling a function that passes a reference to a static function (say Foo) around. If you disassemble the output (objdump -d) you can see in the code, that it doesn't pass a pointer to Foo, but to a different function, which *then* calls Foo. On Sat, Dec 9, 2017 at 2:32 PM, Jakob Borg <ja...@kastelo.net> wrote: > I confess I find the code a bit convoluted and hard to follow - but > doesn’t it just boil down to method values bound to the same pointer, thus > acting on the same struct value (state)? > > https://play.golang.org/p/VVdSyaYp5x > <https://play.golang.org/p/FjP0FXTqTS> > > //jb > > > On 9 Dec 2017, at 09:23, viktor.oge...@gmail.com wrote: > > Hi, > > > I have a problem that I have tried to reduce to a minimal re-producible > example, I have not fully managed but it does show some to me strange > behavior: > > > https://play.golang.org/p/ZCyumUPBos > > > I have a similar set up in a much larger set-up where I seem to see (no > errors reported by race-detector) that sometimes inside a "actionWithState" > the state is not remembered correctly/shared with other instances of > "actionState"s. In this playground example however it always seems to > behave as intended with each actionState's action method using its own > state. In the example above however (I see the same thing) both actions *have > the same address* when printed, how can that be that they behave > differently if they point to the same data? > > > I.e. I have two questions where I would appreciate tips since I cannot > seem to wrap my head around it: > > 1. How can (in this code) actions[1] and actions[2] contain the same > pointers (as seen by fmt.Print) yet behave differently when called as > functions? > > 2. Although the behavior of the example above is what I expected (apart > from it printing the same pointer value), is there any circumstance under > which they would start to "share state" which I have not thought of that > could lead to the problem I am seeing in my larger code-base that you could > think of? > > > Any thoughts appreciated :-) > > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
