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/dfe39769-e5d1-4abc-aec2-e91807cd1b71%40googlegroups.com.
