This commit changes `Iterator`'s API by:
* Generalizing bounds from `Iterator` to `IntoIterator` whenever
possible, matching the semantics and ergonomics of `for` loops.
* Tightens up a few method-level bounds so that you get an error
earlier. For example, `rev` did not require `DoubleEndedIterator` even
though the result is only an `Iterator` when the original iterator was
double-ended.
Closes#23587
The bound-tightening is technically a:
[breaking-change]
but no code should break in practice.
We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or
`unsafe extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Fixes#24161.
This method hasn't really changed since is inception, and it can often be a
nice performance win for some situations. This method also imposes no burden on
implementors or users of `Clone` as it's just a default method on the side.
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095Closes#24119
cc #24014
r? @alexcrichton
These traits are currently all just unstable parts of the facade which are
implementation details for primitives further up the facade. This may make it
more difficult to find what set of methods you get if only linking to libcore,
but for now that's also unstable behavior.
Closes#22025
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095
cc #24014
In addition to being nicer, this also allows you to use `sum` and `product` for
iterators yielding custom types aside from the standard integers.
Due to removing the `AdditiveIterator` and `MultiplicativeIterator` trait, this
is a breaking change.
[breaking-change]
We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or `unsafe
extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Fixes#24161.
* Fix broken \"module-level documentation\" link on the [`trait Any` docs](http://doc.rust-lang.org/std/any/trait.Any.html) and related broken markup on the [`std::any` docs](http://doc.rust-lang.org/std/any/index.html).
* Remove an outdated or incorrect notice in the `BufRead::lines` docs. There is no such `read_string` function, and `lines` never returns an error.
r? @steveklabnik
This adds the missing methods and turns `str::pattern` in a user facing module, as per RFC.
This also contains some big internal refactorings:
- string iterator pairs are implemented with a central macro to reduce redundancy
- Moved all tests from `coretest::str` into `collectionstest::str` and left a note to prevent the two sets of tests drifting apart further.
See https://github.com/rust-lang/rust/issues/22477
Since it doesn't utilize the parameter, it's not very idiomatic since it
could just use the `Result::or` method. So this changes the example to
utilize the parameter. As far as I can tell, all the numbers in this
example are completely arbitrary.
- Added missing reverse versions of methods
- Added [r]matches()
- Generated the string pattern iterators with a macro
- Added where bounds to the methods returning reverse iterators
for better error messages.
There are still some remnants we could remove from the compiler (e.g. references to "subtraitrefs"; traits still have variance entries in the variance table), but this removes all user-visible bits I believe.
r? @pnkfelix
Fixes#22806 (since such traits would no longer exist)
This means passing in e.g. a `Vec<u8>` or `String` will work as
intended, rather than deref-ing to `&mut [u8]` or `&mut str`.
[breaking-change]
Closes#23768
These constants are small and can fit even in `u8`, but semantically they have type `usize` because they denote sizes and are almost always used in `usize` context. The change of their type to `u32` during the integer audit led only to the large amount of `as usize` noise (see the second commit, which removes this noise).
This is a minor [breaking-change] to an unstable interface.
r? @aturon
