output minimal .di files?

[Alex Rønne Petersen]

On 16-01-2012 21:08, H. S. Teoh 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.
>
> 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.
>
> 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
>

I... don't think the error messages from expanding raw object code would 
be very pleasant to read, if you used a template incorrectly...

-- 
- Alex