To add to this issue, that's a problem that is also related to how type equality is treated in the spec and deep equality. If we have some kind of "snapshot" slices for instance, an equality can be determined for these (with some other things to consider) and for structs with fields that are "snapshot" slices.
On Saturday, October 26, 2019 at 7:49:50 PM UTC+2, atd...@gmail.com wrote: > > I get that we can do that but it's not strictly about slices operations > such as appending or copying. > Of course, we could copy slices all the time but then there is no benefit > in having them and it is not ergonomic as your example shows, nor does it > fit your performance cost requirements. > > If you look at the code snippet I posted, I am merely assigning a value of > type slice to a struct field. Now, that struct can be copied a number of > times without its actual value changing. It looks immutable in some sense. > BUT, it's actually implicitly tied to an object that is mutable (backing > array) and nowhere have we made sure that the mutation of this backing > array is safe. > > On Saturday, October 26, 2019 at 7:20:31 PM UTC+2, Gert wrote: >> >> 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/cfa2fdcc-11f3-4400-98df-ab4193c2171b%40googlegroups.com.
