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/bf49fac1-1206-495b-ba69-2eccc3504a84%40googlegroups.com.
