Stabilize unsafe_cell_get_mut

[BoxyUwU]

Tracking issue: #76943

r? @m-ou-se

[m-ou-se]

@rfcbot merge

This change stabilizes UnsafeCell::get_mut().

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @KodrAus
• @dtolnay
• @m-ou-se
• @sfackler
• @withoutboats

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.

[RalfJung]

Cc @rust-lang/lang since UnsafeCell is a language primitive, not just a library type -- but I agree that adding this operation makes sense.

[RalfJung]

@EllenNyan I also have a small proposal for a docs improvement (in the UnsafeCell type docs):

This is showcased by the .get_mut() accessor, which is a non-unsafe getter that yields a &mut T.

Why "non-unsafe"? I think it would make sense to avoid the double negation and just say "safe", in italics for emphasis.

[m-ou-se]

Why "non-unsafe"?

That was the original wording added in #76936. But it looks like there was no discussion about that wording there.

[danielhenrymantilla]

Phrasing it as "non-unsafe" instead of as "safe" is something I usually do,

• (For those curious as to why)

  unsafe, with code formatting, has a very specific meaning, relating to the Rust guarantees w.r.t. memory (un)safety and contractual UB.

  Hence, non-unsafe inherits from this very specific meaning, contrary to "safe", which is kind of ambiguous: for instance, I'd rather say that ::std::fs::remove_dir_all("/") "is not unsafe" or "non-unsafe", rather than saying it is safe 😉.

and which kind of slipped through my implementation PR, sorry. Since Rust's standard documentation does use "safe" without these concerns of mine, there is no reason not to do that here too, so feel free to rephrase it!

[BurntSushi]

@danielhenrymantilla I like that reasoning. But I do tend to avoid using unsafe anywhere other than where it's actually used, because it means grep produces less noise when looking for uses of unsafe. :-)

(I have no opinions in this particular example, but just wanted to throw this out there.)

[BoxyUwU]

I changed the "non-unsafe" to "safe" since no-one seems to have any objections and this is more in line with the rest of docs :)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[m-ou-se]

@bors r+ rollup

[bors]

📌 Commit 1a1a99c has been approved by m-ou-se

[bors]

⌛ Testing commit 1a1a99c with merge 6340607...

[bors]

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing 6340607 to master...

[m-ou-se]

@EllenNyan Congrats on getting your first stabilization PR merged! And thanks again!

[pthariensflame]

Does this need relnotes?