No header files?

[Yigal Chripun]

Walter Bright Wrote:

> Yigal Chripun wrote:
> > On 22/10/2009 02:01, Walter Bright wrote:
> >> Yigal Chripun wrote:
> >>> the only valid IMO use case for header files is for linking libs - the
> >>> compiler can handle just find binary formats for that.
> >>
> >> I was originally going to go with a binary format for that - but it
> >> turned out to be pointless. dmd is so fast at parsing, there simply was
> >> no advantage to replacing the text file parser with a binary file parser.
> >>
> >> If you consider the .di file as a "binary format", I think you'll find
> >> it fulfills all the purposes of it, as well as being human readable
> >> without needing a pretty-printer.
> > 
> > Let me re-phrase myself, since I think you misunderstood:
> > 
> > c headers are used for hiding implementation *and* documentation.
> > the latter is accomplished much better by tools such as ddoc, javadoc, 
> > etc. This leaves us with the former, which doesn't require the format to 
> > be human readable, it doesn't mean you must make it not-readable.
> > 
> > the benefits of using the llvm byte-code format are as following:
> > 1) platform neutral
> 
> Check.
> 
> > 2) has efficient representation for in-memory and an equivalent for 
> > on-disk.
> 
> Check.
> 
> > 3) like with C# and Java, the file *is* the interface, no need to 
> > maintain a separate interface file.
> 
> Check. (D doesn't need bytecode files in addition to .obj files, so LLVM 
> isn't saving on any files compared with D.)
> 
> > 4) already implemented with all the required tooling by the LLVM project
> 
> Check.
> 
> I'm not really understanding what's wrong with .di files.
> 
> Further advantages of .di files:
> 
> 1. Neither .di files nor .obj files are needed for other files to 
> successfully import and reference library code
> 
> 2. .di files are human readable without any need to learn anything other 
> than D
> 
> 3. No new file formats to design, document, debug and maintain
> 
> 4. No extra code needed to implement a .di file reader in the compiler
> 
> 

I think you misunderstood. the idea is *not* to replace .di header files with llvm bit-code files. 
the idea is to replace d object files lib files with a llvm bit-code equivalents  which does not need additional header files.

let's go over the list one more time:
1) i can't use obj files from different OSes or even different compilers on the same OS - so definitly *not* platform neutral 
2) you need to parse a header file in addition to linking functions from the lib file, how is that better than having one file without needing to do any parsing of headers at all? 
3) like Steve said, there is only one file so you don't get syncing problems between the header and the object file. the bit-code object file already contains all the required metadata and doesn't depend on a separate header file.
4)LLVM is already implemented and has all the required tools for its format. ldc for example can take advantage of this easily.