Walter:

> Similarly, template bloat is a language implementation issue that needs 
> eventually to be addressed. Having a kludgy language feature that only 
> addresses 
> printf is the wrong fix.

I don't think you will find a magic solution to remove the problem of template 
bloat.
In past I have shown you three very different ideas to reduce template bloat. 
Just hoping in a better future is not enough. Like with cancer probably there 
is no single solution to remove template bloat, you have to attack this problem 
from many sides at the same time, and one of the sides is to not produce bloat 
when possible, in some different ways.


> As for the rest, having specific compiler support for printf makes for sad 
> sister support for anything else.

Good "pluggable type systems" are a general solution usable for many other 
purposes too, not just for printing functions. What's good of them is that you 
don't need to modify the front-end because they are implemented in user code, 
and you are able to restrict them to parts of a program or to just a program, 
so they become problem-specific and don't make the language more complex for 
all D software projects.

There are many ways to implement pluggable type systems. User annotations plus 
static introspection are a possible syntax to define them. Time ago I have 
discussed about a variable known at compile-time that's similar to the 
__builtin_constant_p() of GCC (http://www.delorie.com/gnu/docs/gcc/gcc_81.html 
), but to be good enough this has to work with libraries too even when you are 
not using whole-program optimization (unlike __builtin_constant_p).

Even if you refuse to add this static tests to the printing functions, like 
they are missing in C and present in both GCC/Clang and Microsoft static tools, 
plus most C lints, they will be done by future D compilers or D lints. LDC is 
possibly going to add this static test.

Bye,
bearophile

Reply via email to