Lending iterators & GAT & the future

1

When reading about lending iterators and GATs, I get the distinct feeling that the current solutions, on stable, are considered to be a little of a workaround, even to the point of being a little "hacky", in the sense that there's a "real/proper" solution looming somewhere beyond the horizon.

If that is the case, what parts are we missing to get the "ideal" lending iterator? Is there a known concrete goal to achieve this, or is it still an area of research? async is mentioned a lot relating to the "* in return position" updates and RTN, but are these some part of the lending iterators puzzle as well? Or have I completely misunderstood it, and we've basically already reached the final destination with regards to lending iterators?

After reading this reply I decided to play around with lending-iterator crate, and I gotta say that it - for my use-case - works incredibly well. Don't really understand why I got scared away from it last time I looked at it. Maybe it was one of the caveats mentioned in the docs? However, I can't see what that would have been, because I tried integrating it into the project I need it in, and it just worked. Still, curious about whether we'll ever see a stable LendingIterator in std, and how that would look.

1 Like
2

Basically the problems explored in this post.

A big one is conditional higher-ranked bounds (and probably types):

Ideally, we would be able to write in a where clause there, so the bounds of print_items could become:

fn print_items<I>(mut iter: I)
where
	I: LendingIterator,
	for<'a where I: 'a> I::Item<'a>: Debug,

I believe that's being worked on as it's required to fix some soundness bugs too. I don't know which way the wind is blowing as to exposing the syntax or how close it is, though.

Whatever is going on with Workaround 1 might be another, but it's too far out of cache for me to summarize it off the top of my head.

And here's another case that's solved by Polonius.

GATs in dyn will remove the need for some workarounds. But wouldn't apply to the "better alternative" necessarily.

A lending iterator trait in core will be required to work with for.

1 Like