Header Files

[Marco Leise via Digitalmars-d]

Am Mon, 11 May 2015 12:50:48 +0000
schrieb "weaselcat" <weaselcat at gmail.com>:

> On Monday, 11 May 2015 at 12:46:59 UTC, Marco Leise wrote:
> > Am Sun, 10 May 2015 10:37:13 -0400
> > schrieb bitwise <bitwise.pvt at gmail.com>:
> >
> >> I'm not sure I understand what you're trying to say.
> >> 
> >>    Bit
> >
> > I'm trying to hijack your thread and communicate that .di
> > files are important for D since they allow the compiler to
> > stop recursively importing modules at some point rather than
> > eagerly importing until "the world" is in compiler memory.
> 
> Is this something that already works?

The idea is very simple. You have some .d file like this:

import a;
import internal;
import std.algorithm;

SomeStruct foo()
{
	return SomeStruct(min(1, 2));
}

The compiler loads and analyzes 'a', 'internal',
'std.algorithm' and publically imported modules. If there are
multiple declarations of SomeStruct it errors out. If
SomeStruct is only defined in 'a', a .di file would reduce to
this:

import a;

SomeStruct foo();

So we remove the dependency on that Phobos module
'std.algorithm' for 'min' and module 'internal'.

Ideally only the public API of a module remains in a .di file,
but we need to know more, like what size it is and if it has a
dtor. There's also compile-time reflection to iterate all the
(private and public) fields in a struct or class making it
harder to completely remove internal modules from the public
API:

import internal_types;

struct IUseInternalStructures
{
private:
	SomeInternalType data;
	uint handle;
        float area;
}

Although for most purposes it is enough to know the .init of
this struct and that it has no dtor (not even one from
SomeInternalData), we cannot really remove the import here in
the .di file.

-- 
Marco