-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change trait RangeArgument to struct RangeBounds. #43033
Conversation
r? @BurntSushi (rust_highfive has picked a reviewer for you, use r? to override) |
5e55907
to
fbd095d
Compare
Hi @clarcharr, looks like there has been a bunch of CI failures like
Is this PR still a work in progress (per your original comment)? |
It is! I'll get back to this today or tomorrow. |
☔ The latest upstream changes (presumably #42727) made this pull request unmergeable. Please resolve the merge conflicts. |
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. |
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? |
OK, I looked a little more closely at the situation.
This PR changes the name and implements the 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? |
Nothing related to this is being stabilized AFAIK. |
@brson I should clarify that this is absolutely not expected to stabilise soon. The intention was to offer an implementation of the If the team would prefer to leave |
I think so. |
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). |
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! |
/// An intermediate trait for specialization of `Extend`. | ||
#[doc(hidden)] | ||
trait SpecExtend<I: IntoIterator> { | ||
/// Extends `self` with the contents of the given iterator. | ||
fn spec_extend(&mut self, iter: I); | ||
} | ||
|
||
#[rustc_deprecated(reason = "moved to core::ops", since = "1.19.0")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would need to be "1.21.0" now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do!
@@ -11,142 +11,7 @@ | |||
#![unstable(feature = "collections_range", | |||
reason = "waiting for dust to settle on inclusive ranges", | |||
issue = "30877")] | |||
#![rustc_deprecated(reason = "moved to core::ops", since = "1.19.0")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do!
pign @clarcharr, just wanted to make sure this stayed on your radar |
@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! |
This follows from the discussion in #30877. This removes the
RangeArgument
trait in favour of theRangeBounds
struct, whereRangeArgument<T>
is loosely translated toInto<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 onRangeBounds<usize>
. That isn't blocking on this commit, but it's something that should be done at some point.