I am fairly certain if you mix pointer and receiver methods and the receiver methods mutate - even if you synchronize those you will get a data race calling the value methods. It must afaik as the runtime/compiler has no implicit synchronization when creating the copies. That is a data race. On Oct
My argument had nothing to do with synchronization.
FTR I find the synchronization argument also extremely dubious. By that
argument, you also can't pass the address to a local variable to another
function, when using it as a value elsewhere. It's a weird argument to
make. time.Time uses a mix of
I am pretty sure it is immaterial. If the object isn’t immutable any copy or mutation operation needs to be synchronized. But the problem afaik is that you can’t control synchronization when the object is copied for a value receiver - which means you cant properly synchronize when you have pointer
No offence, but I made an argument. You don't have to agree with the
argument and it might be wrong. But to convince me, at least, that argument
would need to actually be referenced.
I gave reasons why, in my opinion, *not* mixing value and pointer receivers
sometimes leads to incorrect code. So a
Many places and books I've read generally say: If a function needs to
update a variable, or if an argument is so large that we want to avoid
copying it, we should pass the pointer. Same for methods (pointer
receiver). (The Go programming language book).
About mixing "value receiver" and "pointe
Mixing pointer and value receivers can be race-prone, because of the
copying involved in passing value receivers.
On Mon, Oct 7, 2024 at 12:03 PM 'Axel Wagner' via golang-nuts
wrote:
>
> To be honest, I always found this recommendation a little bit strange,
> personally.
>
> I'll note that the s
To be honest, I always found this recommendation a little bit strange,
personally.
I'll note that the standard library does not really keep to this either.
For example, time.Time.UnmarshalText (obviously) has a pointer-receiver,
while almost all other methods on time.Time have a value receiver.
An
On Mon, Oct 7, 2024 at 10:29 AM Ken Lee wrote:
>
> ---
> There is a consideration to make, though: historically it has been considered
> bad form in Go to give a type a mix of value and pointer receivers in methods
> without a very specific reason for doing so.
> ---
>
> Is this still the case n
