Stabilizing certain intrinsics?

[steveklabnik]

One downside of the blanket description of intrinsics

Unstable (core_intrinsics #0): intrinsics are unlikely to ever be stabilized, instead they should be used through stabilized interfaces in the rest of the standard library

It's not always clear what and how these things may be stabilized. And some people will read the first part and not notice. Also, since they're not really being tracked by an issue, it's easy to let them slip through the cracks.

This came up today specifically in the case of volatile_{load,store}, which will be needed for really low-level development, but also aren't exposed, even in an unstable way, elsewhere.

So, I guess what I'm asking is, how can we make sure that things that are intrinsics don't stay unstable for a really long time? Or rather, come up with what the stable interfaces should be, as I would expect {std,core}::intrinsics to be unstable always, forever, as the message says.

[sfackler]

I believe that the intrinsics module specifically will always be unstable, but individual intrinsics will be exposed in a stable manner in the right place like std::mem::transmute. Seems totally reasonable to expose the volatile operations in std::ptr or std::mem.

[bluss]

Yes the idea is that they are stabilized regular module location outside intrinsics.

unreachable (issue) and needs_drop are both on my wishlist. Performance related. As is drop_in_place, although it has already found a location outside intrinsics, just not stabilized yet.

[Aatch]

I actually wrote an RFC related to this. It’s not exactly the same, but the motivations overlap.