SAL at Microsoft

[bearophile]

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