On Tuesday, 12 June 2012 at 11:09:04 UTC, Don Clugston wrote:
On 12/06/12 11:07, timotheecour wrote:
There's a current pull request to improve di file generation
(https://github.com/D-Programming-Language/dmd/pull/945); I'd
like to
suggest further ideas.
As far as I understand, di interface files try to achieve these
conflicting goals:
1) speed up compilation by avoiding having to reparse large
files over
and over.
2) hide implementation details for proprietary reasons
> 3) still maintain source code in some form to allow inlining
and CTFE
> 4) be human readable
Is that actually true? My recollection is that the original
motivation was only goal (2), but I was fairly new to D at the
time (2005).
Here's the original post where it was implemented:
http://www.digitalmars.com/d/archives/digitalmars/D/29883.html
and it got partially merged into DMD 0.141 (Dec 4 2005), first
usable in DMD0.142
Personally I believe that.di files are *totally* the wrong
approach for goal (1). I don't think goal (1) and (2) have
anything in common at all with each other, except that C tried
to achieve both of them using header files. It's an OK solution
for (1) in C, it's a failure in C++, and a complete failure in
D.
IMHO: If we want goal (1), we should try to achieve goal (1),
and stop pretending its in any way related to goal (2).
I absolutely agree with the above and would also add that goal
(4) is an anti-feature. In order to get a human readable version
of the API the programmer should use *documentation*. D claims
that one of its goals is to make it a breeze to provide
documentation by bundling a standard tool - DDoc. There's no need
to duplicate this just to provide another format when DDoc itself
supposed to be format agnostic.
This is a solved problem since the 80's (E.g. Pascal units). Per
Adam's post, the issue is tied to DMD's use of OMF/optlink which
we all would like to get rid of anyway. Once we're in proper COFF
land, couldn't we just store the required metadata (binary AST?)
in special sections in the object files themselves?
Another related question - AFAIK the LLVM folks did/are doing
work to make their implementation less platform-depended. Could
we leverage this in ldc to store LLVM bit code as D libs which
still retain enough info for the compiler to replace header files?
