Recently merged GAT RFC has some relevance to the API design

[golddranks]

Generic associated types landed just a little over week ago: rust-lang/rfcs#1598 They are still far away from stabilisation, but once they stabilise, they allow expressing the streaming iterator pattern as a trait. This crate also supports parsing in a streaming iterator style, using read_record and read_byte_record. Should some precautions be taken for later adding a trait-based streaming iterator API, or can the API added in a non-breaking way after 1.0?

[BurntSushi]

I'm not doing anything until I can actually play with it. If we need to release a 2.0, then so be it.

[golddranks]

Okay, I'll close this. Let's see when the time is ripe :)

[BurntSushi]

Sorry if I was curt earlier, I was just waking up. :-)

To be clearer, GAT could have an impact here, but it will take a bit I think before I'd be ready to let it into the public API. In particular, one the key advantages will be the existence of a streaming iterator abstraction, which will need to exist somewhere, and it most certainly won't start off life in std. Even if that did exist, the standard iterators in this API would still be around for some time since they work with Rust's for loop, which requires support in the language itself. The read_record APIs themselves are relatively convenient with while let syntax, so to make GATs compelling here, we'd probably want to hook into some other type of abstraction that permits composition of some kind.