fmt,sync/atomic: `fmt` functions should allow integer verbs for atomic integers

[bcmills]

What version of Go are you using (go version)?

go 1.19

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

https://go.dev/play/p/jHX7pcphAmV

What did you do?

Format an atomic.Int32 using the %d verb.

What did you expect to see?

Since an atomic.Int32 “is an atomic int32”, I expected that the fmt verbs that apply for int32 should generate the same representation when applied to an atomic.Int32.

Or, if the %d verb is not expected to work in the same way that it does for an int32, I expect the atomic package docs to note that detail.

What did you see instead?

Applying the %d verb to an atomic.Int32 prints it as a struct, not an integer:

{{} 42}

(CC @robpike @martisch)

[gopherbot]

Change https://go.dev/cl/426456 mentions this issue: fmt: display contained values when formatting atomic booleans and integers

[mknyszek]

I think that passing an atomic.Int32 (or any of the atomic types) by value is technically incorrect since it's noCopy, so the referenced code will fail go vet and the race detector (I hope... haha). However, I think this probably makes more sense for an *atomic.Int32 (is that weird to pass for %d?).

Also, I'm not certain that the documentation already allows the *atomic.Int32 case. Maybe we should also update the docs on the atomic type to not say "is an int32" in any form, since you can't use it by value. (As you suggested.)

If we want to support *atomic.Int32 specifically, maybe this should be a proposal? I'm not sure.

[bcmills]

I think that passing an atomic.Int32 (or any of the atomic types) by value is technically incorrect since it's noCopy

Interesting — the noCopy check does fire if I run go vet manually, but doesn't appear to be included in the standard go test vet checks. 🤔

[mknyszek]

That's odd, I feel like it was at some point because I've definitely had the noCopy check catch something in the runtime tests before, though perhaps I'm just misremembering.