How does D’s ‘import’ work?

[Cecil Ward]

On Wednesday, 31 May 2023 at 18:56:02 UTC, H. S. Teoh wrote:
> On Wed, May 31, 2023 at 06:43:52PM +0000, Cecil Ward via 
> Digitalmars-d-learn wrote:
>> Is there an explanation of how D’s ‘import’ works somewhere? 
>> I’m trying to understand the comparison with the inclusion of 
>> .h files, similarities if any and differences with the process.
>
> Unlike C's #include, `import` does NOT paste the contents of 
> the imported file into the context of `import`, like #include 
> would do. Instead, it causes the compiler to load and parse the 
> imported file, placing the parsed symbols into a separate 
> symbol table dedicated for that module (in D, a file == a 
> module). These symbols are then pulled into the local symbol 
> table so that they become available to code containing the 
> import declaration.
>
> (There's a variation, `static import`, that does the same thing 
> except the last step of pulling symbols into the local symbol 
> table. So the symbols will not "pollute" the current namespace, 
> but are still accessible via their fully-qualified name (FQN), 
> i.e., by the form `pkg.mod.mysymbol`, for a symbol `mysymbol` 
> defined in the module `pkg.mod`, which in turn is a module 
> under the package `pkg`.)
>
> For more information:
>
> 	https://tour.dlang.org/tour/en/basics/imports-and-modules
> 	https://dlang.org/spec/module.html
>
>
> T

Thank you so very much for the links and for your generous help. 
Some C compilers used to have a thing called ‘precompiled 
headers’, potential source of trouble and ai always felt uneasy 
about it rightly or wrongly.

It’s great that D has got rid of header file includes though, 
they were ridiculously painful. I used to use the automake 
feature that was built into the JPI C compiler at work which took 
care of all the .h dependencies so you no longer had to worry 
about it. And you only loaded the compiler from disk and started 
it up once as it stayed in memory handling all the C parts of a 
make.