I think I've misunderstood something about .di files:

$ cat testDI.d
private int foo(){ return 1; }
$ dmd -H -c testDI.d
$ cat testDI.di
// D import file generated from 'testDI.d'
private int foo()
{
return 1;
}

Why does the .di file include the body of foo? In fact, why does it have foo at all? I thought the point of .di files was they just have the public declarations, not the bodies and not the private stuff. Well, except for templates, obviously, but this isn't a template.

What's going on? What am I misunderstanding?

It's because the function is small enough to be inlineable, you can't inline it if you've only got the prototype in the header file. So it's optimizations at play.

On Sat, Oct 22, 2011 at 9:49 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com
> wrote:

> It's because the function is small enough to be inlineable, you can't inline it if you've only got the prototype in the header file. So it's optimizations at play.
>

Interestingly, it looks like GNU ld should be able to inline functions as part of link time optimizations, which would make this unnecessary on platforms where DMD uses ld. Probably not worth looking into right now, but if di files become more used in the future, this sort of thing could probably go away (except on Windows, but the linker situation there is probably one of the most problematic parts of the D toolchain).

It could also be considered a little bit dangerous. E.g. you could forget to regenerate header files after compilation and potentially leave the user code with an old function body.

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.331.1319338165.24802.digitalmars-d-learn@puremagic.com...
> It's because the function is small enough to be inlineable, you can't inline it if you've only got the prototype in the header file. So it's optimizations at play.

I hadn't expected that to happen without specifying -inline. But I guess this way makes sence since it lets the user app decide whether or not to inline.

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.333.1319338819.24802.digitalmars-d-learn@puremagic.com...
> It could also be considered a little bit dangerous. E.g. you could forget to regenerate header files after compilation and potentially leave the user code with an old function body.

...Or specify different compilation options (like version identifiers) when generating the lib/di versus when building your app. Which could leave a chimera of a module, a module built partially with one configuration and partially with another.