Correct, so basically avoid x := y[i:j] if you actually meant copy
https://golang.org/ref/spec#Appending_and_copying_slices
var a = [...]int{0, 1, 2, 3, 4, 5, 6, 7}
var s = make([]int, 6)
var b = make([]byte, 5)
n1 := copy(s, a[0:]) // n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
n2 := copy(s, s[2:]) // n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
n3 := copy(b, "Hello, World!") // n3 == 5, b == []byte("Hello")
On Saturday, October 26, 2019 at 3:02:37 PM UTC+2, atd...@gmail.com wrote:
>
> Hi,
>
> Thank you for the response.
>
> My issue is not really about append but can be illustrated by this :
>
> https://play.golang.org/p/YZlo1mqGDLz
>
> On Saturday, October 26, 2019 at 2:27:06 PM UTC+2, Gert wrote:
>>
>> Sorry, the performance cost is to high. But you can practice a few
>> programming habits that can prevent this, like use x = append(x, y) and
>> never x = append(y, x) Basically we only need a Go proverb bible mentioned
>> in one of Rob Pike's talks and we will be fine :)
>>
>> On Saturday, October 26, 2019 at 1:40:23 PM UTC+2, atd...@gmail.com
>> wrote:
>>>
>>> Hello,
>>>
>>> I've just realized that slices were much more delicate to use than
>>> initially thought. The main issue is that when slices share the same
>>> backing array, it is too easy to inadvertently have an unprotected
>>> concurrent Read/Write if one is not careful.
>>> That can easily happen for a struct that has a field of type slice for
>>> instance. The object might be safe to copy and pass around to multiple
>>> goroutine but reading a value from the slice field can still be problematic
>>> if there is a write at the same time on one of the object's slice field.
>>>
>>> This is not a proposal but for later, would it make sense to have slices
>>> become real snapshots (immutable) or copy/allocate on mutation?
>>> It will probably have perf repercussions.
>>>
>>> Or alternatively a tool that alerts of cases where there are such case
>>> of unprotected concurrent use (perhaps the race detector already does this)
>>>
>>> Even better is if that's a non argument because the cases where it's
>>> happen in real world code is sparse but I must admit that it took me a long
>>> time to think about this and now, I'm worried that it's a mistake too
>>> easily made.
>>>
>>> Also, I do not remember the specifics of the map code, but what happens
>>> for a map of slices? Do the slice elements share the backing array?
>>>
>>>
>>>
>>>
--
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/c8ed31a1-d7f9-4753-bcdc-14c98559c77a%40googlegroups.com.
