Change:
//! references. We say that `Cell<T>` and `RefCell<T>` provide 'interior mutability', in contrast //! with typical Rust types that exhibit 'inherited mutability'. //! <del> //! Cell types come in two flavors: `Cell<T>` and `RefCell<T>`. `Cell<T>` provides `get` and `set` //! methods that change the interior value with a single method call. `Cell<T>` though is only //! compatible with types that implement `Copy`. For other types, one must use the `RefCell<T>` //! type, acquiring a write lock before mutating. </del> <ins> //! Cell types come in two flavors: `Cell<T>` and `RefCell<T>`. `Cell<T>` implements interior //! mutability by moving values in and out of the `Cell<T>`. To use references instead of values, //! one must use the `RefCell<T>` type, acquiring a write lock before mutating. `Cell<T>` provides //! methods to retrieve and change the current interior value: //! //!  - For types that implement `Copy`, the `get` method retrieves the current interior value. //!  - For types that implement `Default`, the `take` method replaces the current interior value //!    with `Default::default()` and returns the replaced value. //!  - For all types, the `replace` method replaces the current interior value and returns the //!    replaced value and the `into_inner` method consumes the `Cell<T>` and returns the interior //!    value. Additionally, the `set` method replaces the interior value, dropping the replaced //!    value. </ins> //! //! `RefCell<T>` uses Rust's lifetimes to implement 'dynamic borrowing', a process whereby one can //! claim temporary, exclusive, mutable access to the inner value. Borrows for `RefCell<T>`s are

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] 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 for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.