Certain &mut self methods of Iterator have a where Self: Sized bound, like try_fold and position. At first, this bound doesn't seem necessary, but as I understand it, this is necessary to make the trait dyn-compatible.
The issue is that only some of the equivalent methods in LendingIterator have the same where Self: Sized bound. In particular, try_fold, try_for_each, and try_find do have it, but all, any, find, find_map, and position don't, even though the equivalent Iterator methods do.
Because traits with GATs cannot be dyn-compatible anyway, one option would be to remove the bound from try_fold, try_for_each, and try_find (and try_reduce if #45 is fixed). However, it is possible that the dyn compatibility restriction on GATs could be lifted in the future, and perhaps it is intended for LendingIterator to become dyn compatible once that restriction is lifted. In that case, the bound should be added to the other methods.
One of the motivations for this is #34. There are many methods that could have a more efficient implementation if it weren't for the mismatched bounds—for example, all could be written in terms of try_for_each if the two methods either both had a Self: Sized bound or both didn't have one.
Certain
&mut selfmethods ofIteratorhave awhere Self: Sizedbound, liketry_foldandposition. At first, this bound doesn't seem necessary, but as I understand it, this is necessary to make the trait dyn-compatible.The issue is that only some of the equivalent methods in
LendingIteratorhave the samewhere Self: Sizedbound. In particular,try_fold,try_for_each, andtry_finddo have it, butall,any,find,find_map, andpositiondon't, even though the equivalentIteratormethods do.Because traits with GATs cannot be dyn-compatible anyway, one option would be to remove the bound from
try_fold,try_for_each, andtry_find(andtry_reduceif #45 is fixed). However, it is possible that the dyn compatibility restriction on GATs could be lifted in the future, and perhaps it is intended forLendingIteratorto become dyn compatible once that restriction is lifted. In that case, the bound should be added to the other methods.One of the motivations for this is #34. There are many methods that could have a more efficient implementation if it weren't for the mismatched bounds—for example,
allcould be written in terms oftry_for_eachif the two methods either both had aSelf: Sizedbound or both didn't have one.