D Language Foundation March 2023 Monthly Meeting Summary

[Walter Bright]

On 4/11/2023 7:35 PM, bachmeier wrote:
> Can't the changes to those files by stored in the compiler? Walter obviously 
> can't change the raw header files, but he can make changes to the files before 
> they're used by the compiler. If that's not possible, can't a modified set of 
> header files be available for download, and if you want to use a system .h file, 
> you have to use the modified version instead?

It's a seductive idea, and I've considered that (and variations on it) many 
times. We have done this, after a fashion, in having our own versions of the .h 
files in the form of the D translations in core.stdc.* import files.

The trouble is, there are endless C .h files out there, and they change 
essentially randomly. We've been tripped up with this by the windows .h files 
changing and breaking our translations of them in druntime.

It's made worse by there being no way for us to realize those .h files have 
changed, while we merrily keep using the existing translations.

Diemos has also had constant problems with changing .h files, which only gets 
discovered when a user runs into a problem.

A huge point to ImportC is to become resistant to arbitrary changes by compiling 
whatever those .h files happen to be. Since we don't have an army of people 
willing to constantly create our own versions of the .h files, it's our only 
practical option.

You can see some of the adaptations for specific .h wackiness in druntime's 
importc.h and _builtins.di files.