Not exactly. I was just trying to show the most direct port possible of the C++. In C++, Increment() is a non-const method, so in Rust I made increment(&mut self).
The point is to show that thread-safe types are expressed differently in C++ and Rust. If you try to do things the C++ way in Rust, it doesn't work.
Strange choice of demonstration, then. The C++ example is thread-safe, so you don't demand any further synchronozation from the caller. The Rust example, by contrast, DOES demand additional (superfluous) sychronization by the caller.
The article makes it seem like Rust type system is just throwing up blockers for no reason.
If your API is satisfactory with an &mut reference, then you don't need an atomic inside.
The point of the exercise is to show that the C++ idiom doesn't make sense in Rust. It's certainly not trying to imply that Rust is being unreasonable for rejecting a direct port of a C++ idiom.
I do think the ambiguity mentioned in the article -- that &mut really means &uniq -- is the core of the confusion. If &mut were called &uniq, I would have had no reason to consider &uniq a direct port of a non-const pointer. That's probably the most important thing I learned when researching and writing this article: that &mut really means "exclusive", not "mutable."
But the C++ example does indeed make sense in Rust, if implemented appropriately. Sometimes you need an atomic, and the type that contains one should require no further synchronization. In both languages it's an equally useful tool.
I agree that more could be done to clarify that &mut should be read "exclusive". You have an opportunity to help in this article. Don't just leave the compiler error and move on, which gives the impression that modifying an atomic is just impossible in Rust... Take the chance to explain why the naive port is not idiomatic.
