Stabilize volatile read and write

[Amanieu]

This stabilizes the volatile_load and volatile_store intrinsics as ptr::read_volatile and ptr::write_volatile.

Rendered

[nagisa]

I think this RFC proposes to do an obviously right change. There’s no compatibility hazard I can think of and the functions are very useful in certain cases.

👍

[shepmaster]

I'd be happy to see these made stable, but are there any environments where these functions can be used without requiring other unstable things? Said another way, would stabilizing these functions make it so that some project can switch from nightly to stable?

I know that doesn't need to be a requirement, and we have to start somewhere.

[nikomatsakis]

Seems like a good idea to me.

[alexcrichton]

As a bit of a bikeshed I might prefer to rename these to read_volatile and write_volatile (to group nicely with the existing read and write), but otherwise this seems fine to me. I believe it meshes well with the rest of the functions in the std::ptr module in terms of naming and signature.

I think the biggest question in terms of stabilization is what does volatile mean, and I agree with this RFC that it's well defined in C and other languages, so I would be fine having documentation redirecting to those relevant documents as well. I would perhaps feel best if we could hash out in this RFC exactly what semantics we'd point to (e.g. what documentation we'd point to) just to be extra sure it's ok, but that's not necessarily required in my opinion.

In the long run I think we'll eventually want a wrapper like Volatile<T> or something like that, but I'm more than ok deferring that and only providing the bare bones in the standard library to start out with (e.g. these functions). I think that you're able to build up everything else on top of these functions.

[Amanieu]

I renamed the functions to read_volatile/write_volatile and added a link to the LLVM definition of volatile.

[alexcrichton]

🔔 This RFC is now entering its week-long final comment period 🔔

---

My own personal opinion is that this is good to go!

[briansmith]

Please do not cite the LLVM documentation as the reference for the semantics. LLVM's documentation doesn't describe standard C semantics, but rather some semantics that are stronger, AFAICT, than what ISO C requires. If Rust wants to be different from ISO C11 then it would be better for Rust to specify what semantics it wants to have, and then verify whether LLVM implements (at least) the wanted semantics. The way this RFC looks now, it will be basically impossible to implement Rust without using LLVM, without reverse engineering LLVM.

[huonw]

@briansmith note that this won't be the first Rust feature that is currently defined in terms of LLVM, nor do RFCs always have be complete specifications (i.e. we may want to learn more about how people want to use a feature before nailing down its semantics completely). Of course, having existing un(der)specified features doesn't automatically imply that we should add more. That said, I would expect documentation to not link to LLVM, but rather give some vague description about approximately what the semantics are (e.g. "volatile reads/writes are never elided nor reordered with other volatile reads/writes"), at least until Rust actually has a spec.

[alexcrichton]

The libs team discussed this RFC during triage yesterday and the conclusion was to merge, so I will do so! Thanks again for the RFC @Amanieu!