Tracking issue for RFC 1651: Extend Cell to non-Copy types

[aturon]

RFC

[SimonSapin]

#39287 broke a library of mine where I had code like this:

trait Take<T> {
    fn take(&self) -> Option<T>;
}

impl<T: Copy> Take<T> for Cell<Option<T>> {
    fn take(&self) -> Option<T> {
        let value = self.get();
        self.set(None);
        value
    }
}

foo.take() 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 added #![feature(move_cell)]. 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 std 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.

[alexcrichton]

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.

[SimonSapin]

If a change to the standard library breaks an excessive amount of code in the ecosystem

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.