I started a new project, where I want to be as modular as possible, by that I mean that I would like to be able to replace some parts with others in the future. This seems to be a perfect use for traits
, at the moment I have this code:
mod parser;
mod renderer;
mod renderers;
use parser::MarkParser;
use renderer::MarkRenderer;
struct Rustmark <P: MarkParser, R: MarkRenderer> {
parser: P,
renderer: R,
}
impl <P: MarkParser, R: MarkRenderer> Rustmark <P, R> {
fn new() -> Rustmark <P, R> {
Rustmark {
parser: parser::DefaultParser::new(),
renderer: renderers::HTMLRenderer::new(),
}
}
fn render(&self, input: &str) -> &str {
self.renderer.render(self.parser.parse(input))
}
}
But I get a couple of errors, mainly this one:
error: mismatched types: expected
Rustmark<P, R>
, foundRustmark<parser::DefaultParser, renderers::html::HTMLRenderer>
(expected type parameter, found structparser::DefaultParser
) [E0308]
And a couple of lifetime errors like this one:
error: cannot infer an appropriate lifetime for automatic coercion due to conflicting requirements
help: consider using an explicit lifetime parameter as shown:
fn parse<'a>(&'a self, input: &'a str) -> &str
I have tried multiple tweaks to make it work, but none of them seemed to appease the compiler. So I wanted to know if this is the right approach and what I could do to to make it work.
First error: you create a Rustmark
object with the field parser
of type DefaultParser
and the field renderer
of type HTMLRenderer
, but the function is expected to return Rustmark <P, R>
. In general P is not of type DefaultParser
and R is not of type HTMLRenderer
, so it will never compile. A good solution if you want have default values of the right type is to bound P
and R
to implement the Default
trait
, this way:
use std::default:Default;
impl <P: MarkParser + Default, R: MarkRenderer + Default> Rustmark <P, R> {
fn new() -> Rustmark <P, R> {
Rustmark {
parser: P::default(),
renderer: R:default(),
}
}
}
Second error: that main problem is that you return a reference of something that probably will die inside the render
method (the String
you allocate in the inner render
method probably). The compiler is telling you that it doesn't know the lifetime of the object that is pointed by that reference, so it cannot guarantee that the reference is valid. You can specify a lifetime parameter but in your case probably the best solution is to return the String
object itself, not a reference.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With