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-nuts@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.
