Comments/prior art on `Atomic<T>`

[LukasKalbertodt]

I was not sure where best to comment this RFC draft. I just wanted to throw a library of mine into the discussion: atomig, which main feature is Atomic<T>.

In atomig's case, the trait bounds on T are a bit more specific and deliberate than in the RFC draft. The docs should explain all the traits fairly well, so I won't repeat myself here.

But one important aspect of having more specific traits: some methods, like fetch_add and fetch_or are bounded by AtomInteger and AtomLogic traits respectively, which in turn are only implemented for types on which integer operations and logical operations make sense, respectively. With the current draft, one could have an Atomic<f32> and call fetch_add on it, but get garbage back, as the atomic add operation is an integer addition. Again, I think the docs should explain this nicely.

Just wanted to throw that out here.

CC @jswrenn

[jswrenn]

With the current draft, one could have an Atomic and call fetch_add on it, but get garbage back, as the atomic add operation is an integer addition.

I don't define fetch_add on Atomic<T> for precisely this reason. I envision basically the solution you describe to accomodate the type-specific methods!

The Atomic<T> extension is the least fleshed out of the hypothetical future possibilities—there's only just enough there to describe the basic pattern. I'll be sure we keep your prior art in mind when we develop Atomic<T> further.