@Crazytieguy It's three different implementations really. I already knew you were working on the GAT implementation from your comments on lending-iterator and still think it's a welcome implementation. I made this mostly to challenge myself and to provide a more 1-to-1 iter LendingIterator. I'm open to any help, and I'll take a look at your repo to see if there's anything I can do to help as well.

Mostly for my own sake, I'll review my understanding of the complexity involved in lending iterator implementations, and then discuss why a GAT implementation is still wanted/welcome. Generally, from most complex/unsound to most simple, the implementations are:

1. lending-iterator's extensive use of dyn trait objects' ability to implement HRTB bounds that are otherwise unimplementable, as a result of #84533.
2. This crate also sparingly using the same dyn #84533 bug/workaround, but looking at the open lending-iterator issue #5, mainly focuses on the underlying #25860 bug ("feature") which allows references to implicitly bind lifetimes in HRTB's at the cost of losing dyn LendingIterator capabilities.
3. Obviously, using Generic Associated Types, which does not utilize any known soundness bug and provides the simplest interface. Additionally, there is the option of type restriction, e.g. streaming-iterator with only references to items.

The GAT implementation is still very welcome:

1. From my own testing, providing a GAT convenience trait on bug-utilizing implementations actually incurs an overall UX loss because it conflicts with <T: LendingIterator> &mut T: LendingIterator. I've also grown to believe that it's not wise to hide soundness-bug-utilizing implementations behind a "friendly" GAT interface.
2. Any bug-utilizing implementation is ultimately... using a bug, and can, at any point in time, be rendered useless by Rustlang or induce undefined behavior. So, not only is a strictly-GAT implementation unique from both this crate and lending-iterator, it is probably the healthiest way to move forward.
3. Although a GAT implementation is "simple" to implement yourself, There's no real reason not to have a crate for it, whether that be so that libraries can use a common API or so that users don't have to handle that work for themselves.
4. Most if not all usage of lending iterators don't actually require a full 1-to-1 iter API. Functional programming aside, for loops are still more than capable and also provide better optimizations in niche cases (e.g. SIMD Vectorizations).

I chose the name lender simply for both convenience and to hopefully give more warning (from the "Neither a borrower nor a lender be" quote flying around everywhere). I don't intend for this crate to be anywhere near some sort of end-all-be-all for lending-iterators.

Oh I somehow managed to miss that you're not using GATs 😅...

Your review is very helpful! My conclusion is that it's worthwhile for me to continue working on my crate. You're definitely welcome to help if you want 🙂. I'm aiming for "as close as possible to something that may end up in the standard library eventually"