The intrinsics do not need to change, the exposed functions can wrap the raw return values up into something more Rusty, like we do for checked arithmetic. This approach is in fact significantly easier than getting the compiler to construct the right enum internally. (Additionally, changing them is entirely unproblematic, they're unstable for a reason)

I don't think anyone would use unwrap: the only reason to use a CAS (rather than just a plain old swap) is if you expect failure. And, try! is mostly similar (although I could imagine propagating a CAS-failure up out of a helper function that is called by some main loop). The fact that these core Result-manipulators don't seem to apply possibly argues for a new enum, but this is a succeeded (Ok)/failed (Err) situation, meaning Result doesn't seem entirely inappropriate to me.

(The first sentence makes me realise: it's somewhat unfortunate that we have mem::swap and Atomic...::swap, but this is ..._exchange, but there's probably not much we can do about that. Having another method with both compare and swap in its name seems like it would just be maliciously designed for maximum confusion with the deprecated compare_and_swap.)

Diving into the details, maybe the return value should be Result<(), T> (or, with a custom enum, enum CasResult<T> { Succeeded, Failed(T) }), since one already knows the old value in the successful case, and, it's often no longer needed anyway (as seen in @Amanieu's snippet).

Tracking issue for compare_exchange #31767

Description

alexcrichtonopenedon Feb 18, 2016

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

alexcrichton
openedon Feb 18, 2016