Description
I'm currently encountering an issue in design of a program that uses the zip crate centered around the function zip::read::read_zipfile_from_stream. I'm using it to create a zipfile struct, however, because read_zipfile_from_stream takes a reference to something implementing the read trait, instead of something taking the read trait itself, I'm finding it impossible to use this function in this instance. That's because I actually pass the ZipFile struct up out of the body where the Vec, and it's corresponding slice, are created that initialize the ZipFile, meaning that I end up invalidating the reference, because the reference refers to the Vec, however, the vec is dropped at the end of the function, whereas the ZipFile is supposed to live beyond that. This issue is intractable because I cannot move where I read the bytes from the stream a level up, and I have designed my own interfaces to take not a reference to something implementing Read, but to borrow something implementing Read. For the reasons above, I need a function exactly like read_zipfile_from_stream, but that does not take a reference. Is this possible to add to the zip crate? Its presence would make possible a much wider range of use cases for read_zipfile_from_stream than are currently possible.
In practice, here's how this occurs:
let buf: Vec<u8> = Vec::new();
// ...Omitted for brevity, but read into buf all of the bytes from some file ...
// Now internally use get_zipfile_from_stream to create a ZipFile from a reference to a buffer
let zipfile: ZipFile = getzipfilefrombufref(&buf[..]);
// whoops, we're about to return something that contains a reference to a buf that is about to go out of // scope
return zipfile;
In practice, it looks like this may be difficult because you've implemented everything in terms of taking references: for instance, your interfaces in podio that are relied upon take mutable references to read. I will think about how this might be overcome.