Borrowing an object as mutable twice for unrelated, sequential uses

Question

I'm trying to implement an abstraction that allows me to read from either a directory or a zip file. I start by implementing something of this sort:

pub trait FileOpener<'a> {
    type ReaderType: Read;

    fn open(&'a self, file_name: &str) -> Result<Self::ReaderType, Box<dyn Error>>;
}

pub struct DirectoryFileOpener<'a> {
    root: &'a Path
}

impl<'a> DirectoryFileOpener<'a> {
    pub fn new(root: &'a Path) -> Self {
        DirectoryFileOpener { root }
    }
}

impl<'a> FileOpener<'a> for DirectoryFileOpener<'a> {
    type ReaderType = File;

    fn open(&'a self, file_name: &str) -> Result<File, Box<dyn Error>> {
        Ok(File::open(self.root.join(file_name))?)
    }
}

But then I realize that the zip-rs package's zip::ZipFile is constructed from a mutable reference to the zip::ZipArchive which it is located in, so I end up with the following code:

use std::path::Path;
use std::error::Error;
use std::fs::File;
use std::io::prelude::*;
use zip::{ZipArchive, read::ZipFile};
use std::marker::PhantomData;

pub trait FileOpener<'a> {
    type ReaderType: Read;

    fn open(&'a mut self, file_name: &str) -> Result<Self::ReaderType, Box<dyn Error>>;
}

pub struct DirectoryFileOpener<'a> {
    root: &'a Path
}

impl<'a> DirectoryFileOpener<'a> {
    pub fn new(root: &'a Path) -> Self {
        DirectoryFileOpener { root }
    }
}

impl<'a> FileOpener<'a> for DirectoryFileOpener<'a> {
    type ReaderType = File;

    fn open(&'a mut self, file_name: &str) -> Result<File, Box<dyn Error>> {
        Ok(File::open(self.root.join(file_name))?)
    }
}

pub struct ZipFileOpener<'a, R: Read + Seek> {
    zip: ZipArchive<R>,
    phantom: PhantomData<&'a Self>
}

impl<'a, R: Read + Seek> ZipFileOpener<'a, R> {
    pub fn new(zip: ZipArchive<R>) -> Self {
        ZipFileOpener { zip, phantom: PhantomData }
    }
}

impl<'a, R: Read + Seek> FileOpener<'a> for ZipFileOpener<'a, R> {
    type ReaderType = ZipFile<'a>;

    fn open(&'a mut self, file_name: &str) -> Result<ZipFile<'a>, Box<dyn Error>> {
        Ok(self.zip.by_name(file_name)?)
    }
}

I'm not sure if that's the most optimal way to write that, but at least it compiles. Then I try to use it as such:

fn load(root: &Path) -> Result<...> {
        let mut opener = io::DirectoryFileOpener::new(root);
        let a = Self::parse_a(opener.open("a.txt")?)?;
        let b = Self::parse_b(opener.open("b.txt")?, a)?;
}

and I get cannot borrow 'opener' as mutable more than once at a time. This does not surprise me much, as I indeed use open(), which borrows opener as mutable, twice - although a is only a u64, and from my point of view it is unrelated to the lifetime of opener.open(), from the compiler's point of view it has to be in the same lifetime of the line below it, and thus we attempt to borrow opener as mutable twice.

However, I then look at the following code, which compiles and works well and which I started this whole thing by trying to improve:

fn load_zip(root: &Path) -> Result<...> {
    let file = File::open(root)?;
    let mut zip = ZipArchive::new(file)?;
    let a = Self::parse_a(zip.by_name("a.txt")?)?;
    let b = Self::parse_b(zip.by_name("b.txt")?, a)?;
}

This throws me off completely, because the function by_name() also borrows zip as mutable, and is also called twice! Why is it allowed to borrow zip as mutable twice here but not in the previous case?

You don't show the declaration of parse_a or parse_b. Those may be important, too. — rodrigo
I didn't include them since they are very long, but they can essentially be replaced with something that consumes the reader and returns some output based on the file's data (e.g. return the 5th byte). Also, how could any possible implementation of those functions make the second use case compile and the first one to fail? They are essentially receiving the same argument (an object implementing the Read trait) — leetrobot
Does this answer your question? Cannot borrow as mutable more than once at a time in one code - but can in another very similar — trent ᶠᵒʳᵐᵉʳˡʸ ᶜˡ
tl;dr the duplicate: &'a self is usually a mistake. &'a mut self is virtually always a mistake. Just remove those 'as; they overconstrain the lifetimes. — trent ᶠᵒʳᵐᵉʳˡʸ ᶜˡ
I see. I understand what you're saying, and it does make sense to remove them. However, this means that I cannot declare e.g. type ReaderType = ZipFile<'a>; in the trait implementation because the lifetime of each ZipFile returned by open() is different! How can I tell the FileOpener trait that open() returns Self::ReaderType with different lifetimes? (also, do you wanna post your answer as an answer so that I can mark it as working?) — leetrobot

leetrobot leetrobot · Accepted Answer · 2020-09-09T14:49:00

After researching the issue and Rust's semantics deeper, and building on top of the notes by trentcl, I came to realize that the problem essentially boils down to defining the FileOpener trait where the lifetime argument is bound to the associated type and not to the trait itself, e.g.

pub trait FileOpener {
    type ReaderType: Read;

    fn open(&'a mut self, file_name: &str) -> Result<Self::ReaderType, Box<dyn Error>>;
}


impl<'a, R: Read + Seek> FileOpener for ZipFileOpener<R> {
    type ReaderType = ZipFile<'a>;
    ...
}

However, this is known as generic associated types (GAT), and is not yet supported in Rust. The GAT RFC does however mention that in some cases the problem can be circumvented by binding the lifetime to the trait itself and using higher-rank trait bounds (HRTB) in the receiving function, which yields the following working solution to this question:

pub trait FileOpener<'a> {
    type ReaderType: Read;

    fn open(&'a self, file_name: &str) -> Result<Self::ReaderType, Box<dyn Error>>;
}

...

fn load<T: for<'a> FileOpener<'a>>(opener: T) -> ... {
    let a = parse_a(opener.open("a.txt")?)?;
    let b = parse_b(opener.open("b.txt")?, a)?;
}

This is because the HRTB allows us to bind T to a FileOpener without binding a specific lifetime to it, which enables the late binding of different lifetimes for each call to opener.open()

Borrowing an object as mutable twice for unrelated, sequential uses

1 Answers