std::ops::Slice is not in the prelude #17710
Comments
|
I believe this was injected by PR #17620 cc @nick29581 |
The new overloaded slice operations have replaced the various `slice` methods on slice types. However, the relevant traits were not included in the prelude, meaning that you would have to manually import `std::ops::Slice` to get these operations -- an unintended regression. This commit adds the traits to the prelude, as is done with most other operator traits. Unfortunately, the trait `std::slice::Slice` (which defines an `as_slice` method) was already included in the prelude. This trait is renamed to `AsSlice`, which is a better name in any case. In addition, because of both `AsSlice` and `Str` traits being included in the prelude, both of which define `as_slice`, and both of which are used for generic programming, this commit renames `ops::Slice::as_slice` to `ops::Slice::as_slice_`. This is a stopgap solution; we'll need to figure out a long-term story here later on. Closes rust-lang#17710 Due to the renamings, this is a: [breaking-change]
|
You should use the slicing notation instead of the slice methods. |
|
Sure, eventually. But going straight to a build error without a deprecation period nor an error message that indicates what to do is unusual for Rust, even pre-1.0. |
|
@nick29581 I thought the sugar was feature gated. Was the gate removed? |
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
|
@pnkfelix I believe it was as part of @aturon's backout, but I didn't check and if it was, it was unintentional. @SimonSapin hard to make an error message for this, since it is just a missing method, but I think we are going to try a smoother deprecation approach |
|
@nick29581 My understanding is that so far, stuff we want people not to use should be marked as deprecated (to emit a warning) with a message indicating the alternative, and not removed from some time (possibly until 1.0). |
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
fix: early exit if unresolved field is an index Fixes rust-lang#17710
fix: early exit if unresolved field is an index Fixes rust-lang#17710
The
sliceand related methods of&[T]apparently have moved to thestd::ops::Slicetrait, but that trait is not in the prelude. This leads to errors such as:This can be “fixed” by adding
use std::ops::Sliceeverywhere, but that doesn’t seem like the intended behavior.The text was updated successfully, but these errors were encountered: