output minimal .di files?

[Adam Wilson]

On Mon, 16 Jan 2012 12:08:53 -0800, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

> On Mon, Jan 16, 2012 at 11:38:15AM -0800, Adam Wilson wrote:
> [...]
>> 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.
> [...]
>
> But if you remove function bodies from inline-able functions, then your
> library loses out on potential optimization by the compiler. Besides,
> all your templates are still world-readable, which, depending on what
> your library is, may pretty much comprise your entire library anyway.

This is a VERY well known deal in the library community. Library writers  
expect that their functions won't be inlined and all template functions  
would be public, they are quite comfortable making the trade-off. If  
you're making a closed-source library, you assume up these things from the  
beginning. It's been that way since the dawn of time and shows no sign of  
changing, at least in the Native Compilation world. The fact that DMD does  
NOT work with DI files as programmers coming from the C/C++ world would  
expect has caused more confusion about DI files than any other subject. It  
certainly confused me. Hence the patch.

DMD needs to offer as seamless a transition as possible, and frankly this  
area of it stinks. No programmer coming to D expects an "Include" file to  
include all implementations by default. This has actually been a subject  
of pain in a number of rants by ex-D programmers who ragequit D. It's not  
an Include file if its got all the implementations, it's a source file.  
Right now, the ONLY difference between .D and .DI is that .DI strips out  
unittests, that's not an include file by any relevant definition of the  
term.

> To *truly* have separation of API from implementation, interface files
> shouldn't even have templated functions. It should list ONLY public
> declarations, no private members, no function bodies, no template
> bodies, etc..  All function bodies, including inline functions, template
> bodies, private members, etc., should be in a binary format readable
> only by the compiler.

That's an API design decision and therefore best left to the library  
writers, it is NOT D's job to enforce that opinion.

> One way to implement this is to store template/inline function bodies
> inside the precompiled object files as extra info that the compiler
> loads in order to be able to expand templates/inline functions, compute
> the size of structs/classes (because private members are not listed in
> the API file), and so on. How this is feasible to implement, I can't
> say; some platforms may not allow arbitrary data inside object files, so
> the compiler may not be able to store the requisite information in them.
>
>
> T
>

Not a bad idea, it's similar in function to .NET's Metadata. unfortunately  
to be useful, other linkers would have to be taught how to read that  
data...

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