-
-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove 'source lifetime #135
Comments
One other thing is that the engine has a few places where that basic model does not work well:
I think a model that could work is to have a |
I had back out one of these due to performance regressions. |
I have a new way now in which I think I want to go about this. The I think what I might be doing for MiniJinja 1.0 and to close off this issue is the following:
Since after you can add owned templates there is not a lot of reason to actually expose the Before: let mut env = Environment::new();
env.set_source(Source::with_loader(|name| {
if name == "layout.html" {
Ok(Some("...".into()))
} else {
Ok(None)
}
})); After: let mut env = Environment::new();
env.set_loader(|name| {
if name == "layout.html" {
Ok(Some("...".into()))
} else {
Ok(None)
}
}); And for owned templates: Before: let mut env = Environment::new();
let mut source = Source::new();
source.add_template("index.html", "...").unwrap();
env.set_source(source); After: let mut env = Environment::new();
env.add_owned_template("index.html", "...").unwrap(); |
Today the engine holds
&'source str
all over the place in the instructions and by extension in the templates. This is a design pillar that I originally inherited from the initial API that was inspired by tinytemplate. It's a pretty clever setup but it has the disadvantage that the API cannot deal with dynamic templates well.The solution to this problem so far has been the
source
feature which introduces aSource
type which lets the engine lie about lifetimes through the use ofself-cell
andmemo-map
.There is a alternative that could be evaluated where these borrows to the source string are not taking place through the references but string handles. That would likely require significant changes in the lexer and potentially the parser as well, but the changes to the instructions are probably quite limited.
The way this could work is that the instructions that currently hold an
&'source str
would instead hold something like aStrHandle
which looks something like this:Obviously one complexity with this approach is that at no point the handles must be separated from the instructions they are contained in. It also comes at least through the safe interface with additional cost as Rust will require a lot more bounds checks.
unsafe
would work here, but actually making a safe interface where someone does not change the source string underneath the instructions accidentally could be quite tricky.The benefit of doing this would be that the engine ends up with less dependencies, overall less unsafe code and a nicer API.
The text was updated successfully, but these errors were encountered: