Right now it is not possible to write a `for` loop without opting-in to the
`core` feature due to the way they're expanding (calling
`::std::iter::IntoIterator::into_iter`). There are some planned tweaks to the
`IntoIterator` trait (adding an `Item` associated type) which will cause
implementations of `IntoIterator` to break, but the *usage* of the trait is
currently stable.
This commit marks the method `into_iter` as stable as the name will not be
changing, nor the fact that it takes no arguments and returns one type (which is
determiend by the `Self` type). This means that usage of `for` loops is now
stable but manual implementations of the `IntoIterator` trait will continue to
be unstable.
This is in preparation for stabilization of the `IntoIterator` trait. All
implementations and references to `Iter` need to be renamed to `IntoIter`.
[breaking-change]
When self.start > self.end, these iterators simply return None,
so we adjust the size_hint to just return zero in this case.
Certain optimizations can be implemented in and outside libstd if we
know we can trust the size_hint for all inputs to for example
Range<usize>.
This corrects the ExactSizeIterator implementations, which IMO were
unsound and incorrect previously, since they allowed a range like (2..1)
to return a size_hint of -1us in when debug assertions are turned off.
New functions, `slice::from_raw_parts` and `slice::from_raw_parts_mut`,
are added to implement the lifetime convention as agreed in rust-lang/rfcs#556.
The functions `slice::from_raw_buf` and `slice::from_raw_mut_buf` are
left deprecated for the time being.
Holding back on changing the signature of `std::ffi::c_str_to_bytes` as consensus in rust-lang/rfcs#592 is building to replace it with a composition of other functions.
Contribution to #21923.
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
r? @alexcrichton
New functions, slice::from_raw_parts and slice::from_raw_parts_mut,
are added to implement the lifetime convention as agreed in RFC PR #556.
The functions slice::from_raw_buf and slice::from_raw_mut_buf are
left deprecated for the time being.
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
This removes the `ByRef` iterator adaptor to stay in line with the changes to
`std::io`. The `by_ref` method instead just returns `&mut Self`.
This also removes the implementation of `Iterator for &mut Iterator` and instead
generalizes it to `Iterator for &mut I` where `I: Iterator + ?Sized`. The
`Box<I>` implementations were also updated.
The extra check caused by the expect() call can, in general, not be
optimized away, because the length of the iterator is unknown at compile
time, causing a noticable slow-down. Since the check only triggers if
the element isn't actually found in the iterator, i.e. it isn't
guaranteed to trigger for ill-behaved ExactSizeIterators, it seems
reasonable to switch to an implementation that doesn't need the check
and just always returns None if the value isn't found.
Benchmark:
````rust
let v: Vec<u8> = (0..1024*65).map(|_| 0).collect();
b.iter(|| {
v.as_slice().iter().rposition(|&c| c == 1)
});
````
Before:
````
test rposition ... bench: 49939 ns/iter (+/- 23)
````
After:
````
test rposition ... bench: 33306 ns/iter (+/- 68)
````
As part of [RFC 474](https://github.com/rust-lang/rfcs/pull/474), this
commit renames `std::path` to `std::old_path`, leaving the existing path
API in place to ease migration to the new one. Updating should be as
simple as adjusting imports, and the prelude still maps to the old path
APIs for now.
[breaking-change]
This removes the `ByRef` iterator adaptor to stay in line with the changes to
`std::io`. The `by_ref` method instead just returns `&mut Self`.
This also removes the implementation of `Iterator for &mut Iterator` and instead
generalizes it to `Iterator for &mut I` where `I: Iterator + ?Sized`. The
`Box<I>` implementations were also updated.
This is a breaking change due to the removal of the `std::iter::ByRef` type. All
mentions of `ByRef<'a, T>` should be replaced with `&mut T` to migrate forward.
[breaking-change]
The extra check caused by the expect() call can, in general, not be
optimized away, because the length of the iterator is unknown at compile
time, causing a noticable slow-down. Since the check only triggers if
the element isn't actually found in the iterator, i.e. it isn't
guaranteed to trigger for ill-behaved ExactSizeIterators, it seems
reasonable to switch to an implementation that doesn't need the check
and just always returns None if the value isn't found.
Benchmark:
````rust
let v: Vec<u8> = (0..1024*65).map(|_| 0).collect();
b.iter(|| {
v.as_slice().iter().rposition(|&c| c == 1)
});
````
Before:
````
test rposition ... bench: 49939 ns/iter (+/- 23)
````
After:
````
test rposition ... bench: 33306 ns/iter (+/- 68)
````
The existence of these two functions is at odds with our current [error
conventions][conventions] which recommend that panicking and `Result`-like
variants should not be provided together.
[conventions]: https://github.com/rust-lang/rfcs/blob/master/text/0236-error-conventions.md#do-not-provide-both-result-and-fail-variants
This commit adds a new `borrow_state` function returning a `BorrowState` enum to
`RefCell` which serves as a replacemnt for the `try_borrow` and `try_borrow_mut`
functions.
Now that associated types are fully implemented the iterator adaptors only need
type parameters which are associated with actual storage. All other type
parameters can either be derived from these (e.g. they are an associated type)
or can be bare on the `impl` block itself.
This is a breaking change due to the removal of type parameters on these
iterator adaptors, but code can fairly easily migrate by just deleting the
relevant type parameters for each adaptor. Other behavior should not be
affected.
Closes#21839
[breaking-change]
These methods were intended to be stable as of #16258 but the tags have since
been lost in various refactorings. This commit re-adds the `#[stable]`
attributes to each of these functions.
The existence of these two functions is at odds with our current [error
conventions][conventions] which recommend that panicking and `Result`-like
variants should not be provided together.
[conventions]: https://github.com/rust-lang/rfcs/blob/master/text/0236-error-conventions.md#do-not-provide-both-result-and-fail-variants
This commit adds a new `borrow_state` function returning a `BorrowState` enum to
`RefCell` which serves as a replacemnt for the `try_borrow` and `try_borrow_mut`
functions.
Now that associated types are fully implemented the iterator adaptors only need
type parameters which are associated with actual storage. All other type
parameters can either be derived from these (e.g. they are an associated type)
or can be bare on the `impl` block itself.
This is a breaking change due to the removal of type parameters on these
iterator adaptors, but code can fairly easily migrate by just deleting the
relevant type parameters for each adaptor. Other behavior should not be
affected.
Closes#21839
[breaking-change]
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.
This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.
Closes#21595Closes#21649Closes#21672
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.
This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.
Closes#21595Closes#21649Closes#21672
These methods were intended to be stable as of #16258 but the tags have since
been lost in various refactorings. This commit re-adds the `#[stable]`
attributes to each of these functions.
