Compiler Bug using D interface file for its intended purpose

[Richard (Rikki) Andrew Cattermole]

On 12/09/2026 2:19 AM, Rambutan wrote:
> 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.

The file extension is irrelevant. The compiler treats them the same.

The difference is -I/-extI vs being compiled in.