If I could unilaterally make just one change to Go, I'd adopt C#-style nullable types, and change everything to be nonnullable without the extra sigil (or whatever, I have no passion about the syntax itself, just the feature). This would produce, say, map[string]string vs. map?[string]string. The first would not be permitted to be null, the second would.
It would be my choice because unlike a lot of other pet ideas which would radically change Go into a new language, I'm pretty sure this would have hardly any effect... excepting of course to remove the Billion Dollar Mistake from the next up-and-coming language.
Well, I'm more or less a programming language nerd and these kind of things just hurt =).
Just try to pass a 'map' or a 'struct' to an other function. The 'map'
behaves like passed by reference and the 'struct' behaves like passed by
value. If you want to pass a 'struct' by reference than you have to use a
pointer to a 'struct'.
Seriously? What kind of ad hoc programming language design is this?
The zero value for a map is nil. The zero value for a struct is a valid struct whose fields are all zeroed. So for pair, that would be (0, 0). The zero value for a pointer is nil. If you had said `var p *pair`, then it would be a pointer to pair, and it would be nil, and you would get a nil panic error.
Just out of curiosity, I ran format in play.golang.org, and it creates tabs with 8 spaces -- really? Is that what the command "go format" will do, too? Is standard go formatting tabs with 8 spaces?
`make` also takes an optional size param that will let you pre-allocate a certain amount of memory if you know the size the map will grow to in advance.
Because I can't see any difference in: