Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for Cell::get_mut and RefCell::get_mut #33444

Closed
tbu- opened this issue May 5, 2016 · 5 comments
Closed

Tracking issue for Cell::get_mut and RefCell::get_mut #33444

tbu- opened this issue May 5, 2016 · 5 comments
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

@tbu-
Copy link
Contributor

tbu- commented May 5, 2016

These methods allow one to obtain a mutable reference to the interior of these cells if you have a mutable reference to the cells themselves.

tbu- added a commit to tbu-/rust that referenced this issue May 5, 2016
This is safe since the borrow checker ensures that we have the only
mutable reference to the struct, thus we can safely borrow its interior.

Tracking issue is rust-lang#33444.
@tbu-
Copy link
Contributor Author

tbu- commented May 5, 2016

As stated in #32565 (comment), I think that a better name for these methods would be as_mut.

@alexcrichton alexcrichton added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels May 5, 2016
@alexcrichton
Copy link
Member

🔔 This issue is now entering its final comment period for stabilization 🔔

The libs team was unfortunately a little late on stabilizations this cycle, but we're thinking of probably doing a backport of stabilizations partway through the beta cycle. This API also follows existing conventions so should be an easy stabilization!

@alexcrichton alexcrichton added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed I-nominated labels Jun 20, 2016
@tbu-
Copy link
Contributor Author

tbu- commented Jun 21, 2016

Looking through the naming convention again, it seems that get is only used for conversions or functions that are not cheap or free, e.g. accessing elements of containers, slices, checking the poisoning state of a mutex and returning the element (with the exception of Unique::get_mut, which isn't stabilized yet).

However, as is often used for this kind of conversion, e.g. Option::as_mut.

I don't think get fits here.

@alexcrichton
Copy link
Member

Ah yes I forgot to mention, but the libs team did indeed discuss the name and concluded that get_mut is the convention here. The get_* prefix is used for containers such as vectors, maps, I/O wrappers, synchronization primitives, etc. The as_* prefix is intended for conversions.

Because these are "containers" and these methods aren't performing conversions, we concluded the appropriate name was get_mut

@alexcrichton
Copy link
Member

The libs team discussed this issue during triage yesterday and the decision was to stabilize. We realize that the FCP for this issue was pretty short, however, so please comment with any objections you might have! We're very willing to backport an un-stabilization for the few APIs we have this cycle.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jul 3, 2016
Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.

Stable

* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
  libstd stabilizations
* `Iterator::sum`
* `Iterator::product`

Deprecated

* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`

Added APIs (all unstable)

* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero

Removed APIs

* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
  unstable

Closes rust-lang#27739
Closes rust-lang#27752
Closes rust-lang#32526
Closes rust-lang#33444
Closes rust-lang#34152
cc rust-lang#34529 (new tracking issue)
bors added a commit that referenced this issue Jul 3, 2016
std: Stabilize APIs for the 1.11.0 release

Although the set of APIs being stabilized this release is relatively small, the
trains keep going! Listed below are the APIs in the standard library which have
either transitioned from unstable to stable or those from unstable to
deprecated.

Stable

* `BTreeMap::{append, split_off}`
* `BTreeSet::{append, split_off}`
* `Cell::get_mut`
* `RefCell::get_mut`
* `BinaryHeap::append`
* `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past
  libstd stabilizations
* `Iterator::sum`
* `Iterator::product`

Deprecated

* `{f32, f64}::next_after`
* `{f32, f64}::integer_decode`
* `{f32, f64}::ldexp`
* `{f32, f64}::frexp`
* `num::One`
* `num::Zero`

Added APIs (all unstable)

* `iter::Sum`
* `iter::Product`
* `iter::Step` - a few methods were added to accomodate deprecation of One/Zero

Removed APIs

* `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is
  unstable

Closes #27739
Closes #27752
Closes #32526
Closes #33444
Closes #34152
cc #34529 (new tracking issue)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

3 participants