Change:
} } <ins> impl<T> Cell<T> { /// Creates a new `Cell` containing the given value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[inline] pub const fn new(value: T) -> Cell<T> { Cell { value: UnsafeCell::new(value), } } /// Sets the contained value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// /// c.set(10); /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn set(&self, val: T) { let old = self.replace(val); drop(old); } /// Replaces the contained value. /// /// # Examples /// /// ``` /// #![feature(move_cell)] /// use std::cell::Cell; /// /// let c = Cell::new(5); /// let old = c.replace(10); /// /// assert_eq!(5, old); /// ``` #[unstable(feature = "move_cell", issue = "39264")] pub fn replace(&self, val: T) -> T { mem::replace(unsafe { &mut *self.value.get() }, val) } /// Unwraps the value. /// /// # Examples /// /// ``` /// #![feature(move_cell)] /// use std::cell::Cell; /// /// let c = Cell::new(5); /// let five = c.into_inner(); /// /// assert_eq!(five, 5); /// ``` #[unstable(feature = "move_cell", issue = "39264")] pub fn into_inner(self) -> T { unsafe { self.value.into_inner() } } } impl<T: Default> Cell<T> { /// Takes the value of the cell, leaving `Default::default()` in its place. /// /// # Examples /// /// ``` /// #![feature(move_cell)] /// use std::cell::Cell; /// /// let c = Cell::new(5); /// let five = c.take(); /// /// assert_eq!(five, 5); /// assert_eq!(c.into_inner(), 0); /// ``` #[unstable(feature = "move_cell", issue = "39264")] pub fn take(&self) -> T { self.replace(Default::default()) } } </ins> #[unstable(feature = "coerce_unsized", issue = "27732")] impl<T: CoerceUnsized<U>, U> CoerceUnsized<Cell<U>> for Cell<T> {}

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.