FileReader doesn't own underlying reader?

[blakesmith]

Hi there!

Is there a reason FileReader doesn't own the underlying reader? StreamReader owns its underlying reader, and as of 0.6.0, FileWriter now owns its underlying writer as well.

I've been trying to work with FileReaders, and have been having trouble with it taking a &'a mut R instead of just R. This makes it hard if I want to store a FileReader in another struct to make multiple calls to the underlying iterator without fighting the borrow checker. For now, I'm using a StreamReader instead, with a file to work around the issue, but StreamReaders seem to have slightly different semantics.

Would it be better for these IO interfaces to consistently take ownership of their underlying readers and writers? Would ya'll accept a patch if so? Happy to post some more concrete examples if that would help!

Thanks for arrow2! It's really been a pleasure to work with so far!

[jorgecarleitao]

I agree. This was an early experiment and I admit I am not happy either. Let's add a into_inner like the std::io::Cursor has, to take ownership back and remove the lifetime.

Would you like to try it out?

Thanks for arrow2! It's really been a pleasure to work with so far!

Thanks! 🙇

[blakesmith]

Thanks @jorgecarleitao! I took a crack at the change in #518, including your into_inner suggestion. I would love to hear your feedback!