Implement TrustedLen and some unstable methods for iterators

[yotamofek]

Hope this is acceptable :)

This impls a few things for IterEither and Either:

• The TrustedLen trait (if both underlying iterators are TrustedLen)
• advance_by (and advance_back_by for DEIs)
• try_fold (and try_rfold for DEIs)

I think this might improve perf in certain use-cases in rustdoc, and might be generally useful for folks using the nightly toolchain compiler. I think having this addition definitely can't heart, and it's gated under a feature flag that hopefully makes it very clear that this might break with every nightly version of rustc.

First two commits are unrelated drive-by cleanups.

[cuviper]

I am generally very reluctant to add "nightly" features in a crate as stable as this, if only because I don't want to be the point of failure blocking anyone if those features do change. The nature of such a flag is clear, but I think it still comes with some expectation of keeping up with nightly rustc.

I think this might improve perf in certain use-cases in rustdoc,

Can you measure that? (e.g. using a [patch.crates-io.either] to your code with changes unconditionally enabled.)

might be generally useful for folks using the nightly toolchain compiler.

I think none of this should have any functional change, only potential performance improvement.

First two commits are unrelated drive-by cleanups.

These are fine, but they should be submitted independently.

[yotamofek]

I am generally very reluctant to add "nightly" features in a crate as stable as this, if only because I don't want to be the point of failure blocking anyone if those features do change. The nature of such a flag is clear, but I think it still comes with some expectation of keeping up with nightly rustc.

I completely understand your reluctance. I was reluctant myself in suggesting this. It's definitely not an ideal situation, and hoping for TrustedLen and try_fold (and friends) to be stabilized soon is probably unrealistic. 🤷

I think this might improve perf in certain use-cases in rustdoc,

Can you measure that? (e.g. using a [patch.crates-io.either] to your code with changes unconditionally enabled.)

I'll try to get a reliable benchmark or some other metric. Honestly I don't remember exactly where I was looking when I started thinking about this, so I'll have to retrace my steps.

might be generally useful for folks using the nightly toolchain compiler.

I think none of this should have any functional change, only potential performance improvement.

Yeah, meant "useful" in the sense of performance 😅

First two commits are unrelated drive-by cleanups.

These are fine, but they should be submitted independently.

👍

[yotamofek]

Opened up #131 with the unrelated cleanup commits,
gonna close this PR for now until I have some convincing numbers to show :)
Thanks for your time and sorry for the noise!