On Fri, May 4, 2012 at 1:46 PM, foobar <[email protected]> wrote: > On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote: > >> On 5/4/12, foobar <[email protected]> wrote: >> >>> The di files are mostly meant to be machine read (e.g. the >>> compiler) and this belongs as part of the library file in order >>> to provide ease of use and maintain the relationship between the >>> binary code and it's interface. >>> >>> maintaining two sets of files that could easily get out of sync >>> and *not* using the docs is way more insane. >>> >>> >> I'd say the docs are more likely to be out of sync than .di code. If >> the .di code is really out of sync you'll likely even get linker >> errors. And not everything ends up being documented. >> >> And then what about existing tools like IDEs and editors. E.g. >> autocomplete wouldn't work anymore. >> > > I'd say you'd be wrong. > Both di and docs are auto-generated from the same source. > As I said docs are designed for human consumption. This includes all sorts > of features such as a table of contents, a symbol index, the symbols should > have links, the docs provide usage examples, etc, etc. > Docs can be put online thus ensuring they're always up-to-date. > > Tools should either read the data from the lib file or retrieve it from > the web. Keeping separate local di files is simply insane. > > And really, have you never heard of Java? How about Pascal? > Should I continue back in history to all the languages that implemented > this feature decades ago? > C/C++ is a huge PITA with their nonsense compilation model which we > shouldn't have copied verbatim in D. >
I like the idea, but what about templates? For them, you'd basically be stuffing source code into the object files (unless you came up with a way to store the AST, but that seems like the effort/benefit ratio wouldn't be worth it since we currently have no way to preserve an AST tree between compiler runs). Otherwise, I find this idea very compelling. I'm sure there are probably other issues, though.
