Change trait RangeArgument to struct RangeBounds.

[clarfon]

This follows from the discussion in #30877. This removes the RangeArgument trait in favour of the RangeBounds struct, where RangeArgument<T> is loosely translated to Into<RangeBounds<T>>.

I'm still working on testing this but I'll upload the PR now and see how people feel.

Additionally, I was going to at some point refactor the code for dealing with ranges of usize into methods on RangeBounds<usize>. That isn't blocking on this commit, but it's something that should be done at some point.

[rust-highfive]

r? @BurntSushi

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

[aidanhs]

Hi @clarcharr, looks like there has been a bunch of CI failures like

[00:01:59] error[E0549]: rustc_deprecated attribute must be paired with either stable or unstable attribute
[00:01:59]    --> /checkout/src/liballoc/lib.rs:214:1
[00:01:59]     |
[00:01:59] 214 | pub use core::ops::Bound;
[00:01:59]     | ^^^^^^^^^^^^^^^^^^^^^^^^^
[00:01:59] 
[00:01:59] error: use of unstable library feature 'range_argument' (see issue #30877)
[00:01:59]   --> /checkout/src/liballoc/btree/map.rs:16:24
[00:01:59]    |
[00:01:59] 16 | use core::ops::{Index, RangeBounds};
[00:01:59]    |                        ^^^^^^^^^^^
[00:01:59]    |
[00:01:59]    = help: add #![feature(range_argument)] to the crate attributes to enable

Is this PR still a work in progress (per your original comment)?

[clarfon]

It is! I'll get back to this today or tomorrow.

[bors]

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

[brson]

This needs to land, and backport, within a week or not at all. It is slated for stabilization on 7/20.

I am not crazy about making API changes at the last minute as this does. A rename - ok (sorta...), but changing how the API works seems unnecessarily risky.

The stabilization of this API is in this backport.

[durka]

I'm a bit confused about the API change, honestly. I see it was suggested #30877 (comment) but there wasn't much discussion. There was consensus around a rename though, but it seems weird to rush the other change -- and why would we backport it for a release before basically anyone has a chance to try it on nightly? Maybe there is more context that I missed?

[durka]

OK, I looked a little more closely at the situation.

1. We decided in the tracking issue to stabilize RangeArgument, and pretty much everyone agreed to change the name but nobody got around to doing it.
2. During FCP, @johncf suggested the "Into trick". Nobody picked it up at the time, indeed @Stebalien and @sfackler had gentle rebuttals, but @clarcharr adopted it for this PR.
3. Right after stabilization, @glaebhoerl complained about the naming.

This PR changes the name and implements the Into trick but does not stabilize anything. The backport stabilizes the API without either of those.

Based on that contradiction it seems to me that we haven't agreed on the design of this feature. Should we just revert the stabilization for now?

[sfackler]

Nothing related to this is being stabilized AFAIK.

[clarfon]

@brson I should clarify that this is absolutely not expected to stabilise soon. The intention was to offer an implementation of the Into version as a POC to make sure that people are okay with it, let the dust settle, then stabilise it. Right now I still have a bit of work to do making BTree*::range work as expected, but I do feel like this is a better way forward.

If the team would prefer to leave RangeArgument as it is and simply rename it for the sake of getting this stabilised quicker, I can modify this PR to do that.

[liigo]

@durka

Based on that contradiction it seems to me that we haven't agreed on the design of this feature. Should we just revert the stabilization for now?

I think so.

[Mark-Simulacrum]

So I'm not clear what the status of this is. I don't think we're backporting this to beta at this point (it's too late).

[sfackler]

There's no need to beta backport this - RangeArgument was un-stabilized.

This does seem like a reasonable way forward though. r=me with a rebase!

[ollie27]

This would need to be "1.21.0" now.

[clarfon]

Will do!

[ollie27]

As this module only contained RangeArgument and that's been removed, this entire module can just be deleted along with its reexports in collections and std::collections.

[clarfon]

Will do!

[alexcrichton]

pign @clarcharr, just wanted to make sure this stayed on your radar

[aidanhs]

@clarcharr I'm going to close this to keep the queue clean, but if you manage to get back to this to rebase let us know and we'll reopen!