I think you need to run your example; the behavior is the same: trying to make an assignment to the non-nested map will panic contrary to what your comment says.
> panic: assignment to entry in nil map —Sam On Mon, Feb 17, 2020, at 10:35, Michel Levieux wrote: > Hi Kloster08, > > In addition to what others have already pointed out, I'd like to bring > you another case that seems problematic to me concerning the > construction of a "usable nil value" for maps, in the sense that a zero- > value map could be written and read right away without any > initialization. > > Here is the example: https://play.golang.org/p/t5RsM1JY3eQ > > Notice in this example that a nested map would not have the same > behaviour as a non-nested one if they can't be allocated properly, > which adds complexity to the language. Also, how would the compiler > know if the value retrieved is going to be read-only (I have a huge > number of examples coming to mind where this would be the case), in > which case one *does not* want the map to be allocated (the current > behaviour is perfect for the use), or if it will be written at some > point in the future. > > Some workarounds might exist, but I think it'd either be irrelevant a > win (if a win it is) and a tremendous amount of work in comparison. > Let aside all code that relies on the current behaviour of nil maps, > be it a "good" or "bad" practice, and that would break because of this > kind of change in the language. > > Hope this helps, > > M.Levieux > > Le lun. 17 févr. 2020 à 15:06, 'Axel Wagner' via golang-nuts <golang- > n...@googlegroups.com> a écrit : > > On Mon, Feb 17, 2020 at 11:18 AM <kloste...@gmail.com> wrote: > >> Out of curiosity: Could you please tell when calling methods on nil > >> pointers is useful? > > > > In general, linked datastructures - like linked lists or trees. As a > > somewhat trivial example, consider this: > > https://play.golang.org/p/Y-4aSVLzEFO Interpreting a nil-pointer as > > "an empty tree" makes a lot of the traversal-algorithms easier to > > express. I also have an internal package that wraps the > > openat/mkdirat/linkat/… class of syscalls, to make it possible to > > still read/write a directory that has been bind-mounted over. It > > uses a struct to encapsulate the file-descriptor of that directory, > > which is used as a pointer to keep track of whether it has been > > closed and such. It also interprets a nil-pointer as "relative to > > the current directory" (it uses AT_FDCWD). I could, of course, also > > use the zero-value of that struct for that (in fact, I do as well), > > but as there is a meaningful way to interpret a nil-pointer, there's > > no harm in doing so as well. > > > > In general, it's of course never *necessary* to interpret a nil- > > pointer a specific way. But it does sometimes make things easier to > > express or nicer to use. > > > > BTW, as far as slices are concerned: They behave strikingly similar > > to maps, as far as the zero-value is concerned - in that all read- > > operations work just fine on both a nil-map and a nil-slice, it's > > just that write-operations panic (and again, in both cases). The > > main difference between them is that *non*-nil maps behave very > > differently. We don't tend to notice the "uselessness" of nil-slices > > in general, though, because we tend to either assume a certain size > > for them (in which case they can't be nil) or we check the length > > beforehand (just like checking if a map is nil) when writing to > > them. i.e. the read-operations are far more common with slices and > > we find the idea of "checking" their nil-ness via ranging over them > > or explicitly checking their len somewhat more natural. > > > -- > > 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/CAEkBMfHAfA97soJy1iXea1H7Bkv_VO%3D43cLY96zi%2BZ7R0a%3DbTQ%40mail.gmail.com > > > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHAfA97soJy1iXea1H7Bkv_VO%3D43cLY96zi%2BZ7R0a%3DbTQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > > . > > -- > 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/CANgi334t%3DNz_7jH7%3D1KZacHi_OfDsq94-dUFpgMf_oKnsa%3D2Mw%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CANgi334t%3DNz_7jH7%3D1KZacHi_OfDsq94-dUFpgMf_oKnsa%3D2Mw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . -- Sam Whited -- 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/929dfda3-36e3-4bd1-85cb-47f55b6b1e11%40www.fastmail.com.
