>This sounds like if you are suggesting to make the zero value of a map >an >empty map, which is different from initializing a map variable to an >empty >map if it a named return. That suggestion has come up a lot, both on >this >list and on the github issue tracker. It's, unfortunately, not as easy >as >it sounds. Here is some prior discussion: >https://groups.google.com/g/golang-nuts/c/SjuhSYDITm4/m/Z013vH5qDQAJ >https://groups.google.com/g/golang-nuts/c/5_8E9OblIho/m/b9O038mzBQAJ >
>> And another reason is that it's very convenient for the zero value >> for >> all types to be literally a sequence of zero bytes. We could >> never figure out how to preserve that property while not requiring >> the >> make call for map values. In the very early days what we call >> maps now >> were written as pointers, so you wrote *map[int]int. >> We moved away from that when we realized that no one ever >> wrote `map` without writing `*map`. That simplified many things >> but it >> left this issue behind as a complication. >> The most plausible fix that I know for this is to invent a map >> function that is similar to the append function, but I haven't yet >> seen a good design for that. I do not need to understand the difficulties that exist, though I struggle to understand the zero bytes property as surely even an empty string has a 4 or 8 byte pointer. Perhaps it is the memory pointed to. Maybe useful for compaction etc.. My original thinking was that either the function call or initialisation could run make under the covers. From Ian in those threads copied above "While not requiring the make call". Why not require make by calling it, behind the scenes? -- 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/AAB589F5-DA04-4468-A745-77F9177EAF76%40gmail.com.
