Remove all unstable deprecated functionality

[alexcrichton]

This commit removes all unstable and deprecated functions in the standard
library. A release was recently cut (1.3) which makes this a good time for some
spring cleaning of the deprecated functions.

[rust-highfive]

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @aturon

A huge amount of stuff ended up getting removed here, and I believe I avoided all stable deprecated items, but a second set of eyes would certainly be useful!

[bors]

☔ The latest upstream changes (presumably #27615) made this pull request unmergeable. Please resolve the merge conflicts.

[bluss]

fwiw, looks good to me.

I caught the deprecation of reverse_in_place here, and it says not performant enough to justify inclusion, deprecated in c14d86f. Is this something that has been a problem? We could probably improve it instead (codegen for match on tuple is known to be inferior).

[bors]

☔ The latest upstream changes (presumably #27688) made this pull request unmergeable. Please resolve the merge conflicts.

[aturon]

OK, I've read over this entire PR. As usual, very satisfying.

My one worry: some of the removals are APIs that were deprecated in 1.3 (currently in beta), whose replacements were also introduced in 1.3. That risks introducing a strong split between the nightly and stable ecosystems.

In general, we want for deprecations to only take effect once a stable release providing their replacement is available -- and the same is even more true for removals. When we haven't done this, e.g. with connect -> join, it's been a hassle for people. We've talked about using the since attribute to not even warn until the relevant release has hit stable.

I'm not sure whether this is a blocker; I feel like we don't have a ton of experience to go from here. Thoughts?

[alexcrichton]

Yeah that's a good point. I like the idea of doing a regular cleaning right after releases are made, so it's probably good to have a formula for something like when we release 1.X we can remove all deprecated items from 1.Y and below (with some relation between X and Y).

Perhaps when say that X == Y? e.g. we don't actually delete anything deprecated in 1.3? That should give a full cycle of deprecation on nightly before deletion I think.

[Gankra]

👍 to letting deprecations hit stable first

On Thu, Aug 13, 2015 at 9:10 AM, Alex Crichton notifications@github.com
wrote:

Yeah that's a good point. I like the idea of doing a regular cleaning
right after releases are made, so it's probably good to have a formula for
something like when we release 1.X we can remove all deprecated items from
1.Y and below (with some relation between X and Y).

Perhaps when say that X == Y? e.g. we don't actually delete anything
deprecated in 1.3? That should give a full cycle of deprecation on nightly
before deletion I think.

—
Reply to this email directly or view it on GitHub
#27684 (comment).

[Stebalien]

My one worry: some of the removals are APIs that were deprecated in 1.3 (currently in beta), whose replacements were also introduced in 1.3. That risks introducing a strong split between the nightly and stable ecosystems.

How is this a problem? The APIs are unstable so they can't be used in beta/stable anyways so the ecosystem was already split.

[alexcrichton]

Er, after thinking about this some more:

In general, we want for deprecations to only take effect once a stable release providing their replacement is available -- and the same is even more true for removals.

I totally agree for stable APIs we want this, but it's not as clear to me that we want this same guarantee for unstable APIs. Once an unstable API is deprecated the second you see that is the second you have the replacement available to you. In that sense I don't think it's as pressing that we leave around unstable + deprecated APIs for a long time.

It's certainly nice to still have a grace period as projects tracking nightly update every so often, but a 2-ish releases may be a bit much.

[aturon]

Oy, yes, as @Stebalien points out I slipped into making a point about stable APIs; for unstable APIs, this is just fine.

@bors: r+

[bors]

📌 Commit 8d90d3f has been approved by aturon

[bors]

⌛ Testing commit 8d90d3f with merge 82b8964...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt