Request for Review: DI Generation Improvements

[timotheecour]

questions:

A) as I understand it, the new di generation will systematically 
strip out the implementation of non-auto-return, non-templated 
functions, is that correct?

B) since there are some important differences with the current di 
files (in terms of inlining optimization, etc), will there be a 
dmd command-line flag to output those stripped down di files (eg: 
-stripdi), so user still has choice of which to output ?

C) why can't auto-return functions be semantically analyzed and 
resolved?
(eg:auto fun(int x){return x;} ) => generated di should be: int 
fun(int x); )

D) can we have an option to strip out template functions as well? 
This could be more or less customizable, eg with a file that 
contains a list of template functions to strip, or simply strip 
all templates). The library writer would instantiate those 
templates to certain predefined values. Eg:

module fun;
T fun1(T)(T x){
	return 2*x;
}
void dummy_instantiate(){
//instantiate to double, and repeat for all desired types, eg 
with a mixin.
	alias double T;
	fun1!(T)(T.init);
}
Then the library writer generates a library (static or shared) 
and the end user uses the templates with one of the allowed types 
(otherwise link error happens). In many cases (eg 
matrix/numerical libraries), all that's needed is a finite set of 
predefined types (eg int,float etc). Bonus points would be if the 
generated di file automatically generates template constraints to 
reflect the allowed types, to have compile time errors instead of 
link time ones.
Having ability to strip templates greatly simplifies distribution 
of code, as it doesn't have to carry all dependencies recursively 
if all one wants is a few predefined types.

D) btw, is there a way to force the instantiations more elegantly 
rather than using dummy_instantiate? in C++ we can just write 
something like: template double fun<double>(double);, but the 
same doesnt in D.