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

Add range notation #19794

Closed
nrc opened this issue Dec 13, 2014 · 6 comments · Fixed by #19858
Closed

Add range notation #19794

nrc opened this issue Dec 13, 2014 · 6 comments · Fixed by #19858
Assignees
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented.

Comments

@nrc
Copy link
Member

nrc commented Dec 13, 2014

Add first class ranges: start..end, start.., and (implicitly) a whole range represented by a struct FullRange. The first two desugar to Range and RangeFrom structs, which implement Iterator and so allow, for example, for i in 2i..10 { }.

@nrc nrc added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Dec 13, 2014
@nrc
Copy link
Member Author

nrc commented Dec 13, 2014

Part of #19148, see RFC.

@nrc nrc self-assigned this Dec 13, 2014
@nrc
Copy link
Member Author

nrc commented Dec 13, 2014

Slight change of plan, the range structs have an iter method to get an iterator, rather than implementing Iterator themselves. Hopefully, one day, they'll implement some Iterable trait.

@nrc
Copy link
Member Author

nrc commented Dec 13, 2014

This means for i in (0..10).iter() { } is ugly as hell, but should look better with Iterable (although I've lost track if that is actually happening). The advantage is we don't need an extra cursor field in the Range structs, which seems like an important win.

@ftxqxd
Copy link
Contributor

ftxqxd commented Dec 13, 2014

Why would we need an iter method? The current Range iterator doesn’t need one, and AFAICT it has the same representation as the one in the RFC, apart from an extra one field which wouldn’t be necessary for sugared ranges, which don’t have support for a step other than 1. The range structs could simply yield their lower bound and then increment it when next is called, right?

@nrc
Copy link
Member Author

nrc commented Dec 13, 2014

Yeah, that makes sense. It means we can't iterate over FullRange, but that is OK (I think), since it will have no surface syntax anyway.

@nrc
Copy link
Member Author

nrc commented Dec 15, 2014

I'm implementing syntax for Range and RangeFrom, depending on how RFCs rust-lang/rfcs#520 and rust-lang/rfcs#498 work out, we might need to add support for RangeTo later.

bors added a commit that referenced this issue Dec 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants