On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic
<andrej.mitrov...@gmail.com> wrote:
On 5/4/12, Steven Schveighoffer <schvei...@yahoo.com> 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
