Compiler Bug using D interface file for its intended purpose

[Rambutan]

On Tuesday, 8 September 2026 at 21:07:20 UTC, Rambutan wrote:
> I started a discussion here, following your suggestion. I'm 
> beginning to understand what the issues are.
>
> https://github.com/dlang/dmd/discussions/23814

After some thought I have formed the following working hypotheses 
about successful linkage of D interface files.

1. A D interface file connected to a D application or project.

The result of compiling a .di file is minimal so as not to 
duplicate parts of the D application they correspond to. 
Nevertheless some necessary implicit type-related symbols may 
well be created by this compilation, so in general such a file 
should be compiled and linked in.

So when connected to a D project, compile and link in its .di 
file, don't just import it.


2. A D interface file generated (or written) to replace C header 
files connected to a C application or project.

There may be missing symbols in using such a file, and because of 
1. above, these will NOT be generated by compiling the .di file 
and linking it in. Instead those symbols need to be generated by 
renaming the file to .d so it is treated as regular D source, as 
the C source it refers to, not being D, will not produce those 
type-related symbols, so the interface file itself has to do 
that. The trickery used to minimize the implied existence of such 
type related symbols does not always succeed, e.g. in the case of 
doubles in structs.

In summary, always compile and link in a D interface file. If it 
is connected to a C project as a D replacement for C header 
files, rename the .di file to a .d file and compile and link that.

---curious if there's any disagreement with this, eager to hear 
feedback.

R.