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

Use ranges for slice notation. #19795

Closed
nrc opened this issue Dec 13, 2014 · 6 comments
Closed

Use ranges for slice notation. #19795

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

Comments

@nrc
Copy link
Member

nrc commented Dec 13, 2014

Blocked by #19794. Part of #19148.

Nominating for p-backcompat-lang, 1.0 because its backwards incompatible since we remove the ..foo notation for taking a slice from the start of some range.

@nrc nrc added I-nominated B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Dec 13, 2014
@nrc nrc self-assigned this Dec 13, 2014
@nrc
Copy link
Member Author

nrc commented Dec 13, 2014

Implementation strategy:

  • Implement Add range notation #19794, with the special case that range notation inside [] uses the old slice machinery.
  • Parse slicing syntax as an index with a range, but check for slicing traits in the compiler.
  • Move implementors of slice traits to using index traits/range.
  • Remove slicing notation syntax and traits, etc. (breaking change). Check that special treatment of slicing is removed.

@quantheory
Copy link
Contributor

👍
If I understand correctly, I believe that #19794 is doable now, but the changes to indexing traits are blocked by #19129 (and possibly other blockers for associated types in general). I think it's probably possible to do most (all?) of the slicing implementations with the current Index/IndexMut, but then when the new Index lands all of the impls will have to change, so it would be simpler if the Index change happened first.

(Also, the removal of ..j will only occur if RFC 498 lands in its current form, but I guess this change will be backwards-incompatible regardless, due to the removal of the existing slicing traits?)

@pnkfelix
Copy link
Member

P-backcompat-lang, 1.0.

@seanmonstar
Copy link
Contributor

With the new array syntax of [u8; ..4], the ..j range doesn't need to be removed, right?

@aturon
Copy link
Member

aturon commented Jan 8, 2015

I believe this is done; nominating for closure.

@nrc
Copy link
Member Author

nrc commented Jan 8, 2015

Yeah, should have been closed when I landed the patch.

@nrc nrc closed this as completed Jan 8, 2015
@nrc nrc removed the I-nominated label Jan 8, 2015
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

No branches or pull requests

5 participants