Add atomic i32 and u32 wrappers

[mahkoh]

Atomic operations on these types are needed for interaction with certain system APIs.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[Manishearth]

Can we just introduce stable APIs without an RfC?

[mahkoh]

There is nothing unstable about it unless you believe the whole "atomic wrapper" design is unstable. I agree that exposing the atomic functions directly would be a much better design. But since the usize-sized wrappers are already stable, copy-pasted versions with s/size/32/ cannot be less stable.

[Manishearth]

That doesn't necessarily warrant circumventing the RfC process. (I'm not sure if that is the case here)

[mahkoh]

There are only two possible results of an RFC: Add atomic wrappers for 32 bit types or don't use any atomic wrappers. Anything between those two would lead to inconsistent design. Since AtomicUsize has already been declared stable without an RFC, the outcome has been decided.

[liigo]

This changed std/core crate, please rfcs first. Or at least add unstable apis.

[Manishearth]

I'm pretty sure AtomicUsize was around way before we worried about stability so much.

You're adding an API that is going to have to be there forever. I get that it's an obvious API to have. I get that it's something that doesn't have any iffyness in stability -- once added, it doesn't need changing. This doesn't change the fact that you're still adding a stable API, which needs an RfC.

It would be a simple RfC which would probably get accepted. But it still needs to exist.

[alexcrichton]

Yes as @Manishearth and @liigo have mentioned, any new API in the standard library now requires an RFC for both inclusion and stabilization. While simple, there are still possible design axes here we may wish to explore which should be done through an RFC.

[mahkoh]

rust-lang/rfcs#1000