The strange looking thing is that by adding an '&' in the *var assignment*,
sync.Locker in the method set Y suddenly accepts the structure X as
implementing Y independent of whether the embedded field sync.Mutex is
direct or pointer.
Requiring an embedded pointer field to satisfy the pointer-receiver
requirement of a method set member seems logically correlated. The
obliteration of that correlation by a distant var assignment (spooky action
at a distance) is, well, strange. Guessing it has something to do with the
heuristics of the type-inferencing system, but a guess is far shy of a
comfortable understanding.
On Thursday, August 27, 2015 at 6:02:55 PM UTC-7, James Aguilar wrote:
Yes. The Lock and Unlock functions require pointer receivers because it
only makes sense to lock the original mutex, not a copy of it. When you
have non-pointer receivers, the receiving object is not the original, it is
a copy.
--Yes. The Lock and Unlock functions require pointer receivers because it
only makes sense to lock the original mutex, not a copy of it. When you
have non-pointer receivers, the receiving object is not the original, it is
a copy.
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
