On Saturday, October 26, 2019 at 10:22:42 PM UTC+2, atd...@gmail.com wrote: > > > On Saturday, October 26, 2019 at 9:47:39 PM UTC+2, Ian Lance Taylor wrote: >> >> 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. >> >> Oh, I hadn't thought about it that way! Interesting. > I still feel like there should be a way to reign in the amount of shared > state in the cases of these "fat" pointers a little bit. Or at least, > inspect it, warn about it more because most people seem to think that > slices are just infinite arrays (hence the need for the extra-level of > indirection/pointer). > But perhaps, the coding patterns/idioms make it a non issue. For future > considerations I guess. >
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. Go made it this far without many programmers throwing monitors out of the window so I think will be fine by making sure we document slices pointers and interfaces in detail. Yes does 3 pages going to be heavy to understand but if you just remember when you encounter weird stuff to just look again at does 3 pages. -- 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/30ac16bc-bc70-40a6-bc79-f41e3536d144%40googlegroups.com.
