如何在 Rust 中没有特征对象的特征的多个实现者之间进行选择？

Question

I have a trait called Dataset which has a single method to retrieve the contents of a file by its name and an associated Error type. The trait is implemented for different filesystem structures, eg a PathBuf for directory-based access or a ZipArchive for access in a compressed zip archive. For testing purposes also exists an implementation for HashMap .

trait Dataset {
    type Error: Error + 'static;

    fn read(&mut self, name: &str) -> Result<String, Self::Error>;
}

Now, I want to deduce depending on a given file name which implementation to use: A directory if the path is an directory, a zip archive if the extension is .zip or .bzip , etc. Consider a function fn run(dataset: impl Dataset) which operates on a dataset. Having the choosing-code inlined, everything works: (Using a Option<PathBuf> is just for this example, the real code looks at the properties of the given path as described above)

let optional = Some(PathBuf::from("/path/to/dataset/.txt"));
match optional.clone() {
    Some(dataset) => run(dataset)?,
    None => run(static_dataset())?,
}

However, I'd prefer to decouple the functionality of (1) “choose an implementor for Dataset ” from the (2) “give the Dataset to the run function”. I hope to make this function more reusable (as not only the run function could make use of (1)) and be more independend on changes of run – consider changes to the signature like adding more parameters.

I tried two approaches:

1. Trait objects

   While I'm not quite happy to use trait objects just for reasons of decoupling, I wouldn't refuse this option ideologically.

    fn with_trait_object(optional: Option<PathBuf>) -> Box<dyn Dataset> { match optional { Some(dataset) => Box::new(dataset), None => Box::new(static_dataset), } }

   But this is rejected with the error message:

    error[E0191]: the value of the associated type `Error` (from trait `Dataset`) must be specified --> src/main.rs:68:60 | 9 | type Error: Error + 'static; | ---------------------------- `Error` defined here... 68 | fn with_trait_object(optional: Option<PathBuf>) -> Box<dyn Dataset> { |

   It makes sense to me, as the Dataset::Error type is in a return position and we don't know the exact size of it when using a trait object.

2. Closure as parameter

   My second approach is what I would prefer regarding its idea: Instead of returning a Dataset to my caller, the caller gives me a closure which will accept the Dataset . Then, the closure can be used to pass additional arguments to the actual processing function. I could also use different closures so I could reuse my “choose the correct implementor” functionality with ease. However, I can't express “this function takes a closure FnOnce which is itself generic over the Dataset trait in its first parameter”. At the moment, I use Result<(), Box<dyn Error>> as return type for the closure, but it would be nice to be generic there, too. Here the erroneous code:

    fn with_consumer_function( optional: Option<PathBuf>, consumer: impl FnOnce(impl Dataset) -> Result<(), Box<dyn Error>>, ) -> Result<(), Box<dyn Error>> { match optional { Some(dataset) => consumer(dataset), None => consumer(static_dataset), } }

I am quite curious that it looks like I can't factor out this piece of code as I can't describe the correct signature of a consumer function. Is there a different way to order the type parameters? Or is there an entirely different approach possible?

A small example can be found on Rust Playground .

Answer 1

You could start out with this:

fn with_consumer_function<DS: Dataset>(
    optional: Option<DS>,
    consumer: impl FnOnce(DS) -> Result<(), Box<dyn Error>>,
) -> Result<(), Box<dyn Error>> {
    match optional {
        Some(dataset) => consumer(dataset),
        None => todo!(), //consumer(static_dataset()),
    }
}

If you want to change the None arm, you would have to create a (generic) method to generate a dataset. You could do so by extending the trait Dataset with a fn static_dataset() -> Self .

The reason the None does not work with a closure is that rust (at least as of now) treats closures as accepting fixed parameters. If consumer accepts a DS in the first branch, it cannot simply accept HashMap in the second - it still must accept the same type: DS .

You could work around this by defining your own trait:

trait DatasetConsumer {
    fn call<DS: Dataset>(self, ds: DS) -> Result<(), Box<dyn Error>>;
}

struct DatasetConsumerRun;
impl DatasetConsumer for DatasetConsumerRun {
    fn call<DS: Dataset>(self, mut dataset: DS) -> Result<(), Box<dyn Error>> {
        println!("{}", dataset.read("info.txt")?);
        Ok(())
    }
}
    
fn with_consumer_function<DS: Dataset>(
    optional: Option<DS>,
    consumer: impl DatasetConsumer,
) -> Result<(), Box<dyn Error>> {
    match optional {
        Some(dataset) => consumer.call(dataset),
        None => consumer.call(static_dataset()),
    }
}

fn main() -> Result<(), Box<dyn Error>> {
    let optional = Some(PathBuf::from("/path/to/dataset/.txt"));
    with_consumer_function(optional.clone(), DatasetConsumerRun)?;
    Ok(())
}

That said, it is more cumbersome to use DatasetConsumer than to use plain closures.

You could also try to implement with_consumer_function as a macro, but I'm not sure I would follow this path.

Answer 2

Also I had a bash at wrestling the compiler into accepting. Here is the Rust Playground

In but I think @phimuemue has has a pretty succinct response. In my case I added an enum for convenience instead of an associated type. And simply within the code avoided the generic by mapping a running closure over the Option . I am not sure if it fits the criterion of factoring out the match arm, but it feels convenient and avoids dynamic dispatch.