On Wed, Mar 3, 2021 at 7:02 PM Sokolov Yura <funny.fal...@gmail.com> wrote: > > I use reflect2 in our custom more robust deepcopy implementation in two > places: > > 1. When I need to grow slice. > Standard reflect package has no way to enlarge slice without call to > reflect.MakeSlice, which allocates unneeded slice header.
Thanks. I filed https://golang.org/issue/44870 for this. > 2. When I need to iterate map. > Using standard reflect package there is no way to iterate map[string]int > without allocation of string header and int for every key-value pair. When > key or values is struct, things become worse. That is how the language works also. Map keys and values are not addressable. Keeping an address for them is very deeply unsafe, and could break irretrievably with future changes to the garbage collector. Or, to put it another way, supporting this functionality imposes limitations on the garbage collector that I don't think we want to impose. I'm not sure what we can do here. Go's map type intentionally does not give programs complete control over memory. It's possible that generics will address some of these use cases. 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/CAOyqgcWzLyD0gn9r25M6HTGoXgUJEwXz-y2qVX4C4%3DGXp8mouQ%40mail.gmail.com.
