On Sat, Mar 13, 2021 at 3:22 PM Kevin Chadwick <m8il1i...@gmail.com> wrote:
> In that case, as far as I understand it, which may be a limited > understanding. I > disagree with this being a useful property. That is your prerogative. I was simply trying to explain why maps work the way they do (and ISTM that if you want to change the way they work, you should really try to understand why they work this way first). I wasn't trying to convince you it's a good thing. > 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. > Neither of these seems relevant. I agree that if the zero value of a map was a non-nil empty map, that you could check the length to see if it is empty by checking it's length. And that comparison to nil would likely be obsolete (though, again, slices work that way and still have a separate nil value and that doesn't seem to bother people). I also don't think anyone disagrees that it would be nice to have the zero value of a map be simply an empty map (that you can write to). Neither of these have anything to do with whether or not the zero value is represented by 0-bytes, though. There are ways to get these properties that would leave the zero value as 0-bytes - for example, a linked list of key-value pairs that uses an append-like builtin. There are ways that get these properties while destroying the property that the zero value is 0-bytes - for example your suggestion of implicitly initializing maps using `make`. What you describe are the language-level semantics of maps - can a programmer compare them to nil, or can they write to it. But this property is not about semantics, it's an implementation restriction. It's just that we can't find a way to implement better semantics, without losing this property or incurring some other significant downsides. 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 > . > -- 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/CAEkBMfEn%3DtodDYcskLGd_PUvwWhZgezMgcEoEEyYjfBSA832NQ%40mail.gmail.com.
