add a trait for external iterator objects #5599
Comments
ghost
assigned 
|
Fixed by 7158102. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
May 17, 2020
Downgrade useless_let_if_seq to nursery
I feel that this lint has the wrong balance of incorrect suggestions for a default-enabled lint.
The immediate code I faced was something like:
```rust
fn main() {
let mut good = do1();
if !do2() {
good = false;
}
if good {
println!("good");
}
}
fn do1() -> bool { println!("1"); false }
fn do2() -> bool { println!("2"); false }
```
On this code Clippy calls it unidiomatic and suggests the following diff, which has different behavior in a way that I don't necessarily want.
```diff
- let mut good = do1();
- if !do2() {
- good = false;
- }
+ let good = if !do2() {
+ false
+ } else {
+ do1()
+ };
```
On exploring issues filed about this lint, I have found that other users have also struggled with inappropriate suggestions (rust-lang/rust-clippy#4124, rust-lang/rust-clippy#3043, rust-lang/rust-clippy#2918, rust-lang/rust-clippy#2176) and suggestions that make the code worse (rust-lang/rust-clippy#3769, rust-lang/rust-clippy#2749). Overall I believe that this lint is still at nursery quality for now and should not be enabled.
---
changelog: Remove useless_let_if_seq from default set of enabled lints
This was referenced Sep 30, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There's currently an example of this in the
treemapmodule, since it's required to set methods likeintersectionin-order. An external iterator is basically a state machine, so they're somewhat painful to write by hand but it's possible to generate them automatically, and that could be tackled at some point (probably post-1.0).The only method the trait will require is
fn next(&mut self) -> Option<T>. A default implementation a wrapper (see{map, set}_advanceintreemap.rs) for integrating withforloops can be provided.Unlike internal iteration that works with a closure, external iterators can be interleaved and keep their state when you break out of a loop. All iterators (forward, reverse, range within a container, counter, etc.) can implement the same interface, which means a generic library like Python's itertools can be written around them.
Blocking on #5598 for now, because this should be done with methods.
The text was updated successfully, but these errors were encountered: