On 2/24/20 4:38 AM, Atila Neves wrote:
There's also the practical question of template instantiations and
compile times even if the DIP that was being discussed were to be
modified in the way suggested.
I want to actually explore this.
There would be one template instantiation (probably) per usage. Not only
that, but the function being called would also have a separate template
instantiation per usage. This could potentially explode code to
undesirable levels.
However, we have some possible mitigation techniques. For example,
writefln should validate the format specifiers against the parameters,
and then call the real writefln with a format string literal.
Second, I would suggest revisiting the idea of "temporary templates"
that I talked about here:
https://forum.dlang.org/post/qrjls8$13je$1...@digitalmars.com. If the
"shim" call is inlined, and the template removed, then you are simply
left with the call to the standard writefln.
This does not reduce compile-times. But I'm hoping we have an answer in
the newCTFE update. We should really explore more ways to make
generative code more palatable. This is D's strength.
I will also note that we did something very similar with switch(string),
where prior to this the compiler did all the "heavy lifting" of
generating the code to convert strings into integers. Now it's done via
a template which accepts all the strings as parameters. I don't think it
was a bad change, and I'm sure it increased compile times and compiler
memory usage. We shouldn't shy away from this type of stuff, but rather
invest in making it better.
Finally, I'd say that I would really prefer a tiny bit of compiler magic
here. I would love for the template that defines the format string to
devolve directly into a string literal if that's the usage --
potentially without actually instantiating the template. It can be a
better option if we are super-concerned about template slowdown.
-Steve
