Unfortunately I don't have any better ideas. My initial solution was to unwrap errors, then I switched to yielding Result from the Iterator. My curiosity is satisfied knowing that no, nobody has yet thought of a way to make this work despite prior work in the area.

That said, I'll continue to think on it and let you know if I think of a nice way to handle this!

One option is that I could enable the feature, but place it behind the unstable feature flag (i.e: it would sit outside the semver guarantees of the crate, but would at least be open to exploration for those that are more adventurous). Would this be useful to you?

Hmmmm well I certainly wouldn't complain. My main objective right now is a functioning parser, so I've just copy/pasted the code from nano_rust, collecting all the tokens up front. If you enabled that feature, it'd probably nerd-snipe me 😅 I think it'd be cool to get lazy tokenizing for sure, and I'd experiment with it undoubtedly.

I've just merged #901, which introduces a new IterParser::parse_iter method. It's behind the unstable feature flag because I'm still not completely happy with the API, but hopefully it's enough to get you started (perhaps in combination with the IterInput type).

You might find the API a little bit quirky at first: the closure is required to ensure that errors generated during iteration aren't accidentally missed - but if you're finding it too cumbersome, that's a useful data point too!

That said, the full 'meat-and-potatoes' solution to this is proper support for pipelined parsers, but there's still quite a bit of work needed to bring that together properly.

Oh wow! Thanks for this! Also interesting about pipelined parsers, hadn't seen that issue yet. Interested to follow progress there!