• Hipreme (36/36) Oct 23 2022 For reducing a D Interface file dependency when generating it
• Nick Treleaven (2/6) Oct 24 2022 This would make a nice blog post if you have one ;-)
• Imperatorn (2/8) Oct 24 2022 Indeed, D needs more blogs
• Andrey Zherikov (3/5) Oct 25 2022 Could you elaborate more on the benefit? Does it reduce
• Hipreme (15/20) Oct 26 2022 The main problem of that is when you actually get an import the

Hipreme <msnmancini hotmail.com> writes:

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:
```d
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:

```d
module a;
import std.stdio;
void printSomething(string a);
```
Using the import inside the function scope, it will make the work 
easier for dmd:
```d
module a;
void printSomething(string a)
{
     import std.stdio;
     writeln(a);
}
```

Will actually generate only:
```d
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.

Nick Treleaven <nick geany.org> writes:

On Sunday, 23 October 2022 at 20:12:46 UTC, Hipreme wrote:
 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:

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

Imperatorn <johan_forsberg_86 hotmail.com> writes:

On Monday, 24 October 2022 at 12:10:19 UTC, Nick Treleaven wrote:
 On Sunday, 23 October 2022 at 20:12:46 UTC, Hipreme wrote:
 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:

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

Indeed, D needs more blogs

Andrey Zherikov <andrey.zherikov gmail.com> writes:

On Sunday, 23 October 2022 at 20:12:46 UTC, Hipreme wrote:
 This will greatly reduce the number of import and dependencies 
 you need if you ever need to distribute a library.

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

Hipreme <msnmancini hotmail.com> writes:

On Tuesday, 25 October 2022 at 12:29:50 UTC, Andrey Zherikov 
wrote:
 On Sunday, 23 October 2022 at 20:12:46 UTC, Hipreme wrote:
 This will greatly reduce the number of import and dependencies 
 you need if you ever need to distribute a library.

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

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.