> > I don't think we should change creation; what about having the first > insert > make the map if it's nil? > > It seems that would be fairly transparent. >
This wouldn't solve the problem that I saw. Whilst, an easy personal fix is to make sure coders always make a map whenever used. I figured a user might quite easily think that := on a returned map would always be safe, like with a string. Making an empty map just to return it and later making a map of a set size, seems odd. I also do not see why you would ever initialise a nil map. After looking into the named return discussion, including Dave Cheney's blog. I also considered that :=, seemed to be the real problem in the end and IMO, the feature with least to offer. > > 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? > > > But that is exactly the loss of "the zero value is all 0 bytes" we are > talking about. AFAICT, it looks like I misread Ian's response as if make could always be used then it would solve the problem rather than being a cause of a compiler complication. -- 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/87d37b24-14ba-1d9c-35eb-eef9832a10bc%40gmail.com.
