output minimal .di files?

[Adam Wilson]

On Mon, 16 Jan 2012 00:25:21 -0800, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Monday, January 16, 2012 00:14:02 Adam Wilson wrote:
>> I'm assuming that your goal is to build either or static or dynamic
>> libraries?
>>
>> If that is the case than you can assume that CTFE and inlining will not
>> work anyways. This is an inherent limitation of libraries and not D.  
>> What
>> D currently does is assume that you want everything to work, and spits  
>> out
>> your implementation code symbol-for-symbol. The only thing I've found  
>> that
>> D ever strips out of DI files is unittests. I have written a patch for  
>> DMD
>> that strips out non-template class/function implementations with the
>> understanding that CTFE and inlining will no longer work. Templated
>> functions and classes retain their implementations, this is in line with
>> the way C++ operates. Unfortunately my patch isn't well tested yet so I
>> haven't opened the pull required to get it included into the main line  
>> DMD
>> code. But it's a available from my Git account
>> [https://LightBender@github.com/LightBender/dmd.git] if you don't mind
>> building DMD yourself.
>
> Inlining and CTFE should work just fine as long as everything that you're
> trying to inline or use with CTFE is in the .di file. Sure, whatever you  
> strip
> out of the .di file won't work with CTFE or inlining, but inlining and  
> CTFE
> should work just fine with dynamic libraries, exactly like if you had  
> stuff in
> the .h file in C++. You just have to be willing to have it in the .di  
> file.
>
> And you _still_ get the benefits of a dynamic library, since the symbols  
> don't
> get duplicated between programs which share the library. It's just that  
> you
> still have to recompile everything that it's in the .di file, so less  
> can have
> its symbol hidden (for Windows anyway - there is no symbol hiding in  
> shared
> libraries in linux). But you can definitely using inlining and CTFE with
> dynamic libraries.
>
> - Jonathan m Davis

I would say the main reason for using .h/.di files in libraries is that  
the library designer does not want his implementation public viewable. And  
in D, unlike C/C++, .di files are pretty much exclusive to the concept of  
libraries. I'd say that, based on how many questions are raised about .di  
files, almost no one expects the current behavior, I certainly didn't,  
hence my patch. The DI generation patch currently implements the C++  
paradigm, where templated function implementations are publicly viewable,  
but non-templated function implementations are not. I feel that this  
paradigm, being the currently accepted convention, is the best path for D  
to take.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/