Skip to content
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

container/iterator improvements + small changes #8582

Closed
wants to merge 10 commits into from
Closed

container/iterator improvements + small changes #8582

wants to merge 10 commits into from

Conversation

thestinger
Copy link
Contributor

5f3a637 r=huonw
934a5eb r=thestinger
0f6e90a r=cmr

@graydon
Copy link
Contributor

graydon commented Aug 19, 2013

Hm. Is range_inclusive really important? It's just range with one greater on the argument, no?

@thestinger
Copy link
Contributor Author

@graydon: it lets you work around overflow, since range(0, int::max_value) will be one short of the full range

@alexcrichton
Copy link
Member

Is that a common enough use case to have a function in std for it? It seems like at that point you should just have a local mut variable.

@thestinger
Copy link
Contributor Author

I want to get rid of the old range functions in {,u}int-macros.rs so this is replacing part of the functionality of range_step_inclusive (with it being extended to handle steps other than 1 later).

I do expect iterating over [0 .. u8::max_value], [0 .. u16::max_value], etc. to be more than just a corner case though so I think it's worth including.

@asb
Copy link

asb commented Aug 19, 2013

FWIW, I'm with @thestinger on range_inclusive being useful for iterating over all of u8 or u16, and to be honest I prefer it to adding +1 to the top of the range even outside of those usecases.

thestinger and others added 9 commits August 20, 2013 22:05
this works on any container with a mutable double-ended iterator
@thestinger and I talked about this in IRC. There are a couple of use
cases for a persistent map, but they aren't common enough to justify
inclusion in libextra and vary enough that they would require multiple
implementations anyways.

In any case, fun_treemap in its current state is basically useless.
@thestinger thestinger mentioned this pull request Aug 21, 2013
bors added a commit that referenced this pull request Aug 21, 2013
@bors bors closed this Aug 21, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 7, 2022
…earth

Changelog for Rust 1.60.0 🦀 (Kudos to everyone who contributed!)

As always, I'm impressed by how much stuff happened in just one release. Seriously, kudos to everyone who contributed.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants