Embed Notice

Good vouch for Bill's design chops, though:

"In Odin, I have atomic operations, but I don't have atomic types but I've been considering the types."

This is actually the correct direction of how to design atomics. Atomic operations are the fundamental, hardware-mirroring, low-level design. But then you put types on it for the same reason that Ryan advocated for shortened names: it's such a ridiculously common operation, and certain objects will never, ever be modified non-atomically, ever, and anytime you'd want the benefits of non-atomics you want it done safely from the comfort of an optimizing compiler that's proven all the bits necessary to just start doing shit non-atomically where it matters. C++ and C got this wrong in their designs, they started with atomic objects, but needed atomic "accesses" (operations).

Linus also complained about this on the LKML, and C++ fixed it with atomic_ref in C++26. C has no fix for this, because it doesn't have references and because _Atomic(T)* and _Atomic T* are "pointer to atomic object T" and _Atomic(T*) is just "atomic pointer to object T" (e.g., just the accesses to the pointer are atomic).

Not great.

It is, unfortunately, something that is entirely unrepresentable in C at the moment. It needs to be fixed, but it won't for quite some time I'm sure because C is slow as balls to recognizing its mistakes and moving to fix them. Alas!