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?

Answer 1

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()