On 3/13/21 1:40 PM, Axel Wagner wrote:
> 
> Compiler complication is not the concern. It would be easy to build any of the
> suggested semantics into the language. It is just that none of the suggestions
> so far seem clearly better - that is, they all come with their own downsides.
> 

OK, I really meant, GC complexity, etc. Perhaps it does not affect that either.

> The concern about the zero value consisting of 0 bytes is more about
> performance. As long as that's the case, initialization is very close to free.
> As soon as the zero value becomes some non-zero bytes, they have to be written
> and that incurs a cost. 
> 
> When we say "the zero value of a map should only contain zero bytes", what we
> mean is that if I write
> var m map[int]int
> that should a) reserve some memory for m (currently that's as many bytes as a
> pointer needs) and b) those bytes should be zero after that.
> If "make was called implicitly" or anything like that, those bytes wouldn't be
> zero anymore - they would contain a pointer to an allocated map header.
> 
> It's as simple as that. You might feel that preserving that property is not
> important or less important than having a useful zero value for maps. That's
> fine. But that's the property Ian is talking about.


In that case, as far as I understand it, which may be a limited understanding. I
disagree with this being a useful property. Replacing a map of 0 length with one
that is larger is not a problem. Checking the length of a map also makes more
sense to me than nil.

Though I personally do not agree with Nulls in JSON either. An intentional empty
is always more useful. Similarly, nulls when permitted always being
unintentional is more useful in my eyes.

-- 
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/b962ffa5-0201-bffb-90c0-8f6de262d9a7%40gmail.com.

Reply via email to