On 06/11/2012 09:37 AM, timotheecour wrote:
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?
This is my understanding as well.
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 ?
You could use cp instead of dmd -H.
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); )
Conditional compilation.
version(A) int x;
else version(B) double x;
else static assert(0);
auto foo(){return x;}
would need to be stripped to
version(A){
int x;
int foo();
}else version(B){
double x;
double foo();
}else static assert(0);
which is a nontrivial transformation.
This is just a simple example. Resolving the return type conditionally
in the general case is undecidable, therefore, making it work
satisfactorily involves a potentially unbounded amount of work.
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.
You could use overloads instead and use templates for implementing them.
Templates are generally only exposed in a well-designed library
interface if they work with an unbounded number of 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.
For example:
T foo(T)(T arg){return arg; pragma(msg, T);}
mixin template Instantiate(alias t,T...){
static assert({
void _(){mixin t!T;}
return true;
}());
}
mixin Instantiate!(foo,int);
mixin Instantiate!(foo,double);
The nested function named '_' is unnecessary. It works around a DMD bug,
mixin t!T is 'not yet implemented in CTFE'.
