Jack Wrenn

Making `clippy::missing_trait_methods` configurable sounds fantastic!

I'm fairly convinced that this useful. I do think we need to generalize it to an arbitrary number of previous elements. I also think we could use const generics here...

The simplest thing we can do, right now, is to `return`, rather than truncate. That won't totally discard the test, but it will avoid most of the computational overhead of...

I agree it's time to do this, and we already have several PRs pending for it. However, now the blocker isn't MSRV, but rather dependencies. At the time those PRs...

Like [`array_chunks`](https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.array_chunks)? Or something else?

This is a neat idea! You can even make it a little more generic: ```rust use core::ops::RangeFrom; pub fn itemize(iter: I, mut start: RangeFrom) -> impl Iterator where I: Iterator,...

I'm going to go ahead and add this to itertools. The `RangeFrom` formulation is compellingly powerful, and the `Zip` return type means it has almost no maintenance burden.

I'd like to take the approach described in https://github.com/rust-itertools/itertools/pull/814#discussion_r1439725414; i.e.: - We privately fork the `Try` trait and implement it for `Option` and `Result`. - We name our methods with...

Yes, avoiding conflict with libcore is important, and it's why I'm recommending using the `maybe_` prefix. Without RFC2845 implemented, the conflict would cause a compile error. With RFC2845 implemented, our...

Thanks for the report! We'll add `thumbv6m-none-eabi` to our CI and gate the internal use of the unavailable atomics accordingly.