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.
