@Sam, hi, yes, that was the point ^^ My example was here to say "ok, so let's say the first case works because we have made uninitialized maps work, but how do we handle the second case?" It was not made to be runnable as is, I just wanted it to be readable :)
Sorry if that was not clear Le lun. 17 févr. 2020 à 18:23, Sam Whited <s...@samwhited.com> a écrit : > 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 > . > -- 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/CAL4P9zyF1MV23X-3tKTT_Vnj8L-_nWat6tzHBW2YaP7QtA9n6A%40mail.gmail.com.
