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.

[aturon]

Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep take and replace as unstable. I propose we immediately stabilize these APIs.

@rfcbot fcp merge

[rfcbot]

Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @sfackler

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.

[alexcrichton]

ping @BurntSushi (checkbox)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period is now complete.

[SimonSapin]

What’s the next step here? Batch stabilization PR near the end of the release cycle?

[aturon]

@SimonSapin Yep, I'm preparing one right now.