Tracking issue for Atomic*::{get_mut, into_inner} #35603
Labels
B-unstable
Blocker: Implemented in the nightly compiler and unstable.
final-comment-period
In the final comment period and will be merged soon unless new substantive objections are raised.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
alexcrichton
added
B-RFC-approved
Merged
bors
added a commit
that referenced
this issue
Aug 19, 2016
Implement RFC 1649 cc #35603 rust-lang/rfcs#1649 r? @alexcrichton
sfackler
added
B-unstable
|
@rfcbot fcp merge Seem like some nice APIs to have, and also not contentious |
|
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, 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. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 psst @alexcrichton, I wasn't able to add the |
alexcrichton
added
the
final-comment-period
|
The final comment period is now complete. |
bors
added a commit
that referenced
this issue
Dec 18, 2016
Library stabilizations/deprecations for 1.15 release
Stabilized:
- `std::iter::Iterator::{min_by, max_by}`
- `std::os::*::fs::FileExt`
- `std::sync::atomic::Atomic*::{get_mut, into_inner}`
- `std::vec::IntoIter::{as_slice, as_mut_slice}`
- `std::sync::mpsc::Receiver::try_iter`
- `std::os::unix::process::CommandExt::before_exec`
- `std::rc::Rc::{strong_count, weak_count}`
- `std::sync::Arc::{strong_count, weak_count}`
- `std::char::{encode_utf8, encode_utf16}`
- `std::cell::Ref::clone`
- `std::io::Take::into_inner`
Deprecated:
- `std::rc::Rc::{would_unwrap, is_unique}`
- `std::cell::RefCell::borrow_state`
Closes #23755
Closes #27733
Closes #27746
Closes #27784
Closes #28356
Closes #31398
Closes #34931
Closes #35601
Closes #35603
Closes #35918
Closes #36105
willmo
added a commit
to willmo/rust
that referenced
this issue
Jul 8, 2018
This allows them to be used in #[repr(C)] structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this issue
Jul 10, 2018
Add #[repr(transparent)] to Atomic* types This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit. This was briefly part of rust-lang#51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Jul 10, 2018
Add #[repr(transparent)] to Atomic* types This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit. This was briefly part of rust-lang#51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tracking issue for rust-lang/rfcs#1649
The text was updated successfully, but these errors were encountered: