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 slicing syntax instead of methods and add a feature gate #17620

Closed
wants to merge 4 commits into from

Conversation

nrc
Copy link
Member

@nrc nrc commented Sep 29, 2014

cc @aturon

r? anyone?

@rust-highfive
Copy link
Collaborator

warning Warning warning

  • These commits modify unsafe code. Please review it carefully!

@sfackler
Copy link
Member

Does it really make sense to deprecate methods if the replacement is feature gated?

@@ -3407,9 +3407,9 @@ may be specified with `..`. For example:
# let x = 2i;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three lines above, .. needs to be changed to ... as well (i.e., ‘A range of values may be specified with ....’)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh whoops, that change shouldn't even be part of this branch.

@Gankra
Copy link
Contributor

Gankra commented Sep 29, 2014

Can you do collections::btree as well?

@nrc
Copy link
Member Author

nrc commented Sep 29, 2014

@sfackler yes, I think so. They are feature gated because the syntax might change, not because they might go away. Slicing syntax is definitely the preferred use.

@aturon
Copy link
Member

aturon commented Sep 29, 2014

I agree with @sfackler: I would prefer not to deprecate until slice syntax is "officially" supported, rather than encourage people to opt in to a feature gate. The reasons to have this behind a feature gate are (1) working through bugs and (2) the fact that at least the [] syntax may (in fact, is likely to) change or disappear before we finalize. (And the mut syntax may change as well, I know @nikomatsakis had some further thoughts on that.)

That said, it seems fine to land the internal use of this syntax for now.

I'm willing to review this PR.

@@ -3813,7 +3813,7 @@ type signature of `print`, and the cast expression in `main`.
Within the body of an item that has type parameter declarations, the names of
its type parameters are types:

```
```ignore
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you undo the deprecation, please remove the ignore here. (And in general, better to add a silent #[allow(deprecated)] but otherwise keep the test.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason I couldn't add attributes to this code snippet - I tried to allow slicing syntax but there was no way I could get it to work.

@aturon
Copy link
Member

aturon commented Sep 29, 2014

Hm, so I just noticed that the new Slice traits take indices by reference, whereas the RFC takes them by value. This is an issue for the Index trait as well. As far as I know, taking them by value is strictly more general, because you can always say:

impl<'a> Slice<&'a Idx, T> for U { ... }

to allow references with arbitrary lifetimes. But for Copy data (the common case, since these are usually uints), allowing it to go by value is more convenient.

@aturon
Copy link
Member

aturon commented Sep 29, 2014

We may want to resolve the by val/by ref issue before moving forward here.

@aturon
Copy link
Member

aturon commented Sep 29, 2014

We may want to resolve the by val/by ref issue before moving forward here.

Nevermind -- this only affects usage of the methods directly, not the syntax. We should still consider what's desired, but we can move forward with this PR.

fn split_at(&self, mid: uint) -> (&'a [T], &'a [T]) {
(self.slice(0, mid), self.slice(mid, self.len()))
((*self)[..mid], (*self)[mid..])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a shame the (*self) is needed here. Is that fundamental?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is a choice - when looking up the trait method we don't autoderef the receiver (self has type &&[T] here) - that is just a flag we pass in to the trait matching algorithm though, so it should be easy to change. However, I was following what index does, I assume we should be consistent with that, one way or the other.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I don't know why index is implemented that way. Perhaps @pcwalton does?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should be consistent, but I'm not sure that the current design of things like Index is where we want it to be. I know that @nikomatsakis has been thinking about this, especially as it related to method dispatch issues elsewhere.

@aturon
Copy link
Member

aturon commented Sep 29, 2014

Ok, I've finished reviewing -- looks great overall, this is a nice readability win!

I'm curious to hear more about the (*self) issue in particular, but that's more a question of the slice syntax mechanism than this library work. Otherwise, r=me with the deprecations lifted.

Deprecates slicing methods from ImmutableSlice/MutableSlice in favour of slicing syntax or the methods in Slice/SliceMut.

Closes rust-lang#17273.
[breaking-change]

If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
bors added a commit that referenced this pull request Oct 2, 2014
This PR reverts #17620, which caused a significant regression for slices.

As discussed with @alexcrichton, all of the public-facing changes of the earlier PR need to be rolled back, and it's not clear that we should move the libraries over to this new notation yet anyway (especially given its feature-gated status).

Closes #17710
bors added a commit that referenced this pull request Oct 2, 2014
This PR reverts #17620, which caused a significant regression for slices.

As discussed with @alexcrichton, all of the public-facing changes of the earlier PR need to be rolled back, and it's not clear that we should move the libraries over to this new notation yet anyway (especially given its feature-gated status).

Closes #17710
lnicola pushed a commit to lnicola/rust that referenced this pull request Jul 28, 2024
Edition aware parser

Fixes rust-lang/rust-analyzer#16324 by allowing us to properly thread through the edition to the parser
RalfJung pushed a commit to RalfJung/rust that referenced this pull request Aug 1, 2024
Edition aware parser

Fixes rust-lang/rust-analyzer#16324 by allowing us to properly thread through the edition to the parser
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