For reducing a D Interface file dependency when generating it with the -H flag for DMD, you can't import a module on the top level.
Take a look at that example:

module a;
import std.stdio;
void printSomething(string a)
{
   writeln(a);
}

If you generate the .di interface file while using dmd, it will pretty much generate:

module a;
import std.stdio;
void printSomething(string a);

Using the import inside the function scope, it will make the work easier for dmd:

module a;
void printSomething(string a)
{
    import std.stdio;
    writeln(a);
}

Will actually generate only:

module a;
void printSomething(string a);

This will greatly reduce the number of import and dependencies you need if you ever need to distribute a library.

On Sunday, 23 October 2022 at 20:12:46 UTC, Hipreme wrote:

This would make a nice blog post if you have one ;-)

On Monday, 24 October 2022 at 12:10:19 UTC, Nick Treleaven wrote:

Indeed, D needs more blogs

On Sunday, 23 October 2022 at 20:12:46 UTC, Hipreme wrote:

Could you elaborate more on the benefit? Does it reduce compilation time for dependency? If so then how much?

On Tuesday, 25 October 2022 at 12:29:50 UTC, Andrey Zherikov wrote:

The main problem of that is when you actually get an import the user does not need to know.
This is especially useful for dub projects, which if you import an internal dependency of the project, think of a renderer.

I have the HipremeRenderer which uses OpenGL and DirectX-D. What if I show that I'm importing directx-d which is so huge? What if I'm just showing my .di files and the library file? The user would not be able to use the library without getting directx-d. And even worse, if I already guarantee that my renderer is self contained, why would I make someone need to import another library just to use mine? This is how it helps, the compilation times depends on how much code your dependency have, if it was std.regex, it could save you 2 to 3 seconds.