4 ms·
I suppose that makes sense when I think about it for a bit. My recent expectations come from work in Rust. There the language prevents you from mutating a map w
by scottlamb 3y ago
I suppose that makes sense when I think about it for a bit. My recent expectations come from work in Rust. There the language prevents you from mutating a map while holding a reference into it. Go doesn't have a mechanism to prevent that (except the one you said, simply not supporting those references at all). If you had a reference into a map that was resized because of a subsequent mutation, your reference would have to keep the whole previous map alive and point to different memory than a reference acquired since then. Both seem undesirable.
With array slots, the same issue is present but is a bit more explicit because those resizes happen with `mySlice = append(mySlice, ...)`.
- erik_seaberg 3y agoI think the slice append semantics are very error-prone, and it would have been better if a slice was a shareable reference to a single mutable thing, like a map (or a list from Python or Java or …)
- konart 3y ago>If you had a reference into a map Maps in golang are of reference type, just to be clear. https://go.dev/blog/maps https://go.dev/blog/maps implementation: https://go.dev/src/runtime/map.go https://go.dev/src/runtime/map.go
- foldr 3y agoIndeed, removing values from a map while iterating over it in Go is safe and guaranteed to have the expected behavior.