nil map assignment panics. can we do better?

[abuc...@newrelic.com]

Is there anything written down on why assignment to a nil map causes a panic? I'm curious if there were carefully considered tradeoffs while making this decision.

Assignment to nil maps has caused most of the unexpected panics I've seen. Many times these happen in production and cause an incident. Every time it happens I think, "we've got to do something about this."

I'm not sure what the best solution is yet, but there must be something better than the status quo. Would it be possible to have assignments automatically initialize a nil map?

Thanks,

Alex

[Ian Lance Taylor]

I agree that this is awkward. But we've never been able to think of a
way to make an assignment to a nil map initialize the map without also
preserving the very useful property that the zero value of any Go type
can be represented by a sequence of zero bytes.

Ian

[abuc...@newrelic.com]

Ah, thanks Ian, that's exactly the kind of requirement I was looking for.

(also, you said "without" but you probably meant "while")

Perhaps this is a job for "go vet". And/or, looks like staticcheck.io has a check I can try: https://staticcheck.io/docs/checks#SA5000

[Marcin Romaszewicz]

Could we have an operation like append() for slices?

How about:

m := insert(m, "key", "value").

It returns m unchanged if it's allocated, otherwise, it allocates. We're already familiar with this kind of function.

-- Marcin

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d9cc8fb3-7d73-48c0-8c60-9d9b1022054c%40googlegroups.com.

[Jan Mercl]

On Tue, Sep 24, 2019 at 10:11 PM Marcin Romaszewicz <mar...@gmail.com> wrote:
>
> Could we have an operation like append() for slices?
>
> How about:
>
> m := insert(m, "key", "value").

A slice is a value but a map is implemented as a pointer. IOW, the
line of code quoted above updates only the locally visible copy of m.
All other copies of m are left at the old, possibly nil, value, but
that's not how maps in Go work. Once the map is initialized, all the
shared copies can access the same values/operations on it.

[Dan Kortschak]

You can write that.

func insert(m map[K]V, k K, v V) map[K]V {
if m == nil {
return map[K]V{k: v}
}
m[k] = v
return m

> > https://groups.google.com/d/msgid/golang-nuts/d9cc8fb3-7d73-48c0-8c60-9d9b1022054c%40googlegroups.com?utm_medium=email&utm_source=footer
> > >
> > .
> >
>
>

[abuc...@newrelic.com]

Changing how people use maps, or how the language defines/implements maps, feels like a dead end.

I tried the nil-map-assignment static analysis provided by staticcheck.io, but it didn't find our most bug unfortunately. So maybe we need to think about how to implement better static analysis for this.