Yes, the issue is twofold.

Because everything is passed by "copy", it might feel safe to pass around 
structs with slice fields, especially and perhaps unknowingly as "interior 
fat pointers" in structs. 
But, one should remember that these objects are always shallow copies in 
the sense that map/slices/functions will refer to the same underlying 
elements and not be dissociated. 
Thus it could be nice to have a way to enforce deeper copies at the 
language level as well.

The second issue that is related to the first one is that in the case of 
mutliple access by different goroutines, 
this problem can be compounded since the objects can seem to be naturally 
thread safe but the slice operations for instance are not. 
Perhaps is it even the same issue if we send slices through channels if for 
some reason, the backing arrays are shared, I don't know. 

Main thing is that I don't trust the fact that many beginners will have 
thought about this (or perhaps it is just me who didn't). 
Especially when passing objects to different functions that may mutate an 
object internals thinking it is just a copy.

On Monday, October 28, 2019 at 9:44:24 AM UTC+1, rog wrote:
>
>
>
> On Sun, 27 Oct 2019, 21:31 Dan Kortschak, <d...@kortschak.io <javascript:>> 
> wrote:
>
>> This is not necessarily due to races. You can have this exact situation
>> occurring in single threaded code. I don't think any mention of race
>> issues was made here.
>>
>
> The thread subject mentions goroutines and the original message talks 
> specifically about concurrent access, which sounds very much like it's 
> race-related to me.
>
>>
>> On Sun, 2019-10-27 at 08:53 +0000, roger peppe wrote:
>> > On Sun, 27 Oct 2019, 00:04 Gert, <gert....@gmail.com <javascript:>> 
>> wrote:
>> > 
>> > > I believe it's going to be to hard to write a go vet analyser that
>> > > could
>> > > warn to detect unintended state change on a array from two
>> > > different
>> > > pointers.
>> > > 
>> > 
>> > Isn't that why we have the race detector?
>> > 
>> > -- 
>> > > 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 golan...@googlegroups.com <javascript:>.
>> > > To view this discussion on the web visit
>> > > 
>>
>> https://groups.google.com/d/msgid/golang-nuts/30ac16bc-bc70-40a6-bc79-f41e3536d144%40googlegroups.com
>> > > <
>> > > 
>> https://groups.google.com/d/msgid/golang-nuts/30ac16bc-bc70-40a6-bc79-f41e3536d144%40googlegroups.com?utm_medium=email&utm_source=footer
>> > > >
>> > > .
>> > > 
>> > 
>> > 
>>
>>

-- 
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/7560f6d2-ca55-48ea-a874-5b972ddf40a6%40googlegroups.com.

Reply via email to