Request for Review: DI Generation Improvements

[Timon Gehr]

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'.