Here's a reason to not deprecate them: if an existing exported struct type has an int64 field used with atomics like StoreInt64, changing that field type to atomic.Int64 would technically be a breaking change. For example:

type Foo {
    Counter int64
}
--
type Foo {
    Counter atomic.Int64 // breaking change
}

We could still add a hint to the old APIs to point out that the new named types exist, though.

I don't think there is any need to deprecate the old functions. They work. There's nothing wrong with them.

I think if someone was starting a new codebase they should use the new types+methods, but in existing codebases there's no reason to force/nudge people to use the new way.
So maybe a comment saying "consider using ... instead" would be ok, but deprecation is more strident than that.

The old way is more memory efficient than new ways on 32-bit architectures, which is another reason it should not be deprecated.

The old way is more memory efficient than new ways on 32-bit architectures, which is another reason it should not be deprecated.

That doesn't seem right; I thought that part of the reason these types were added was so they'd get compiler support to prevent misalignment on those architectures. You might get a smaller struct if you don't use them, but your atomic operations might not work either, right?

@mvdan, it's true that changing the type of an existing field would be a breaking change, but “avoiding a breaking API change” is IMO one of the few good reasons to add new usage of a deprecated API.

@randall77

They work. There's nothing wrong with them.

I guess that's true of the 32-bit functions, but for the 64-bit functions there is a prominent BUG comment that also gets rendered on https://pkg.go.dev/sync/atomic and perhaps in other places.

It may be true that “they work” subject to that caveat, but that seems like a far cry from “nothing wrong with them”. 😅

The Pointer variant also has the downside of being inherently type-unsafe to use. (The other variants are often also type-unsafe in practice, since one may end up converting between a named integer type and the operand type, but they're at least theoretically usable for variables of unadorned types.)

@bcmills I guess you're right. By my reasoning that switching to (or from) any named type can be a breaking change, we would never be able to deprecate a type. But that's clearly not right; sometimes there are good reasons to deprecate a type.

I think if someone was starting a new codebase they should use the new types+methods, but in existing codebases there's no reason to force/nudge people to use the new way.

Doesn't “deprecate” imply exactly that — avoid in new code, still works for existing code? (That's certainly how I interpret it, but maybe I've spent too long in Google's codebases. 🤔)

Doesn't “deprecate” imply exactly that — avoid in new code, still works for existing code?

I think there's a slight disconnect because some people treat deprecation notices as more imperative. For example, staticcheck uses them as warnings, and some people like me treat staticcheck warnings as CI errors. I would have to go out of my way to tell staticcheck that, in a particular case, that deprecation warning is OK to keep because I must follow semver. Which I guess is fine for the edge case - but that is why "still works for existing code" isn't true out of the box for any staticcheck users.

@go101

The old way is more memory efficient than new ways on 32-bit architectures, which is another reason it should not be deprecated.

Which cases are more memory-efficient? The new way does force correct alignment for 64-bit fields, but the implementation of the old functions also requires the user to manually perform that same alignment in portable code.

I would be ok with deprecating just the 64-bit ops on 32-bit platforms.

@bcmills

On 32-bit architectures

• the size of type A is 12
• the size of type B is 16.
• the size of type C is 16
• the size of type D is 24

If C and D are used as array elements, then the latter will consume more memory.

type A struct {
    x int64
    y int32
}

type B struct {
    x atomic.Int64
    y int32
}

type C struct {
    A
    x int32
}

type D struct {
    B
    x int32
}

the size of type D is 24

Is that a bug in the compiler implementation of align64?

The documentation for unsafe.Sizeof says:

For a struct, the size includes any padding introduced by field alignment.

but I don't see anything that would require unsafe.Offsetof(D{}.x) >= unsafe.Sizeof(B{}). 🤔

Maybe the implemenation is to satisfy unsafe.Sizeof(D{}.B) == 16.

If I'm reading the current unsafe package docs correctly, unsafe.Sizeof(D{}.B) would be 16 even if unsafe.Offsetof(D{}.x) is only 12.

(That's because unsafe.Sizeof is defined to report the size of a variable declared as var v = D{}.B, not the actual number of bytes occupied by the B field within the struct.)

I'm not sure whether or not it is a bug.
I hope it is a bug so that I don't need to expand nested types to save memory under some scenarios. ;)

package main

import (
	"sync/atomic"
	"unsafe"
)

type T struct {
	_ [0]atomic.Int64
	x int32
}

type A struct {
	T
	v int32
}

type B struct {
	_ [0]atomic.Int64
	x int32
	v int32
}

func main() {
	println(unsafe.Sizeof(A{}), unsafe.Sizeof(B{})) // 16 8
}

@go101 That is not a bug. At least, it is intentional. The Go compiler does not attempt to pack some fields into padding needed by other fields.

It is possible we could do that, but it gets tricky. For instance, this program prints 0:

package main

import "unsafe"

type T struct {
	z [2]*byte
	x int32
	// there is a padding int32 here
}

type A struct {
	t T
	v int32 // can we store v in the padding of t?
}

func f(a *A) {
	a.t = T{}
}
func main() {
	var a A
	// put a value in the padding
	*(*int32)(unsafe.Pointer(4 + uintptr(unsafe.Pointer(&a.t.x)))) = 99
	f(&a)
	// is it still there?
	println(*(*int32)(unsafe.Pointer(4 + uintptr(unsafe.Pointer(&a.t.x)))))
}

The compiler is currently fast-and-loose with data in padding fields - in this case it is easier to zero a T by just writing 24 bytes of zeroes. It would be more complicated to avoid clobbering the padding fields, which would be required if some containing type was using the padding fields for actual data.

Deprecate in Go means that we show a warning for code that uses the existing functions. The old atomics are not broken enough to warrant that kind of warning and the developer time that dealing with the warnings will consume.

(Compare to deprecating MD5, or deprecating math/rand.Read - those are far more likely to be real problems in programs.)

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group