Tracking Issue for `unsafe_cell_access`

[pitaj]

Feature gate: #![feature(unsafe_cell_access)]

This is a tracking issue for direct access APIs on UnsafeCell (without going through raw pointers).

Public API

// core::cell

impl<T> UnsafeCell<T> {
    pub unsafe fn replace(&self, new_value: T) -> T;
}
impl<T: ?Sized> UnsafeCell<T> {
    pub unsafe fn as_ref_unchecked(&self) -> &T;
    pub unsafe fn as_mut_unchecked(&self) -> &mut T;
}

Steps / History

• ACP: UnsafeCell access APIs libs-team#521
• Implementation: add UnsafeCell direct access APIs #136398
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[nazar-pc]

Is there something else needed before FCP can start here? The implementation is straightforward, but it uses #122034 internally, not sure if there is a correlation between the two.

[pitaj]

I think we typically want to allow some time for the feature to be used before stabilizing it.

[nazar-pc]

Can the same API be added to SyncUnsafeCell?

[jacobsa]

I have a perhaps dumb question: why is as_ref_unchecked unsafe? It seems to me that the only functions that need to be unsafe are the ones that upgrade from shared to exclusive reference. The safety requirements on this one just say "don't violate the aliasing rules", but that would require calling one of those functions, all of which are already unsafe (right?).

[wleslie]

@jacobsa Introducing a safe UnsafeCell::as_ref would be a backwards-incompatible change, as its existence places a new burden on preexisting codebases to justify that their usage of UnsafeCell is correct.

A piece of code that writes to an UnsafeCell must ensure that there are no conflicting accesses (read or write). Today, such conflicting accesses can only occur in unsafe contexts. But UnsafeCell::as_ref would make it possible for conflicting access to occur in safe code as well. Now, a writer would need to ensure that the &UnsafeCell has never been exposed to safe code, because if it has been exposed, that safe code may have obtained a reference that would conflict with the write.

[Amanieu]

I frequently find the need to use these methods when working with UnsafeCell in low-level concurrency code.

@rfcbot merge libs-api

[rust-rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.