-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add operator overloading to atomic types. #7423
Comments
This worries me a bit. Using overloaded operators for atomics seems prone to abuse or misuse. Using methods makes it clear something special's going on, order of evaluation doesn't depend on operator precedence. I believe that evaluating complex math with atomics is not common. |
Visiting for triage, I agree that these are unlikely to be used very often and could cause confusion. I think almost every use case for atomics in Rust will be to implement concurrent data structures, with a rare case of a They aren't really part of the user-level concurrency idioms in Rust (message passing), so it's okay if they aren't pretty. |
Triage. Do we actually want this? I personally don't. While "C++ does it" is usually a good argument, it is not an absolute argument. |
Closing this due to the general opinion being that atomics should force you to think about memory ordering and related semantics. |
Fix use_self ICE changelog: Fix ICE rust-lang#7423 r? `@flip1995`
The C++ atomic types overload specified operators, defaulting to a sequentially consistent ordering, we should do the same.
Due to the semantics of atomic operations, however, this is blocked on assignment operator overloading (since
a += b
is a different operation toc = a + b
) (#5992)The text was updated successfully, but these errors were encountered: