First of all thanks for this very fast and informative answer!
The idea was to keep the template as hygienic as possible regarding access to outer symbols and make it behave similar to a separate module. However, since internally it is nothing more than a string mixin (and some setup), it would be no technical problem to offer that as an alternative. It could look something like this:
mixin(compileDietTemplate!("template-file.dt", "res.bodyWriter"));
What about
mixin(compileDietTemplate!("template-file.dt", res.bodyWriter));
?
The reason is similar to why this is done in normal modules (i.e. when you import some module it will not inherit symbols from this importer's scope); It could mean that you accidentially pass wrong things to the template and it means that now not only the explicitly passed symbols are "magically existent" inside of the template, but also all symbols that are available because of imports or other declarations inside of the source file. Especially in multi-developer scenarious this could lead to unclean and strongly coupled code. The current way at least provides one place that documents which variables are actually usable by the template.
Is my view that a diet template is basically a part of the instantiating context, that just happens to be in a different file, correct?
And if so, could we make it behave more like that? I would volunteer for this.Definitely in most cases templates are only used in a single place, so in this sense it is part of that context. And although I would like to keep the interface as strict/clean as possible, such a mixin seems to enable a number of fair use cases.
If you want, you can give it a shot. But since implementing this is only a matter of seconds and because I wanted to choose a better name for parseDietFile anyway, I wouldn't really mind doing it, too (I'd try to do it ASAP).
Thanks a lot! This would be awesome!