On Friday, 4 May 2012 at 19:13:21 UTC, Steven Schveighoffer wrote:
On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic
<[email protected]> wrote:
On 5/4/12, Steven Schveighoffer <[email protected]> wrote:
Current tools: read .di files and extract API
new tools: read .dobj files and extract API.
I'm not really seeing the difficulty here...
I thought he meant libraries that are only distributed in
binary form.
So no .di files anywhere. Maybe I misunderstood..
No reason for .di files if the object file already serves as
the interface file.
I think he meant that object (and library) binary files would
be augmented by API segments that provide what di files provide
now -- an interface-only version of the code. It doesn't have
to be text, it can be binary (maybe even partially compiled).
The really nice thing you get from this is, the compiler now
would use this object file instead of .d files for importing.
So not only do you eliminate errors from having two possibly
separately maintained files, but the compiler can build *extra*
details into the .dobj file. For example, it could put in
metadata that would allow for full escape analysis. Or tag
that a function is implied pure (without actually having to tag
the function with the pure attribute).
-Steve
Exactly :)
