On Sat, Oct 26, 2019 at 10:50 AM atd...@gmail.com <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.
For better or for worse, the Go language has shared state. This is most obvious when using pointers: if you copy a pointer, you do not copy the memory to which that pointer points. If that is clear, then the thing to remember about slices is that they are pointers. Pointers in Go do not permit arithmetic. Slices in Go are pointers that permit bounded arithmetic. Ian -- 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/CAOyqgcXPmriK_C9w7GhwyzOyJzzZT8DJ7uvSa-Uq%3DQwBTKJNtg%40mail.gmail.com.
