[imtringued]

What do you mean by "no context can leak into it"? Do you mean it shouldn't export transitive imports?

As in `#include <vector>` also performs `#include <iterator>` but `import vector` would only import vector, requiring you to `import iterator`, if you wanted to assign `vec.begin()` to a variable?

Or is it more like it shouldn't matter in which order you do an import and that preprocessor directives in an importing file shouldn't affect the imported file?

[ninkendo]

Not GP, but I take it to mean I can’t do:

    #define private public
    #import <iostream> // muahaha

Or any such nonsense. Nothing I define with the preprocessor before importing something should effect how that something is interpreted, which means not just #define’s, but import ordering too. (Importing a before b should be the same as importing b before a.) Probably tons of other minutiae, but “not leaking context into the import” is a pretty succinct way of putting it.

[TylerGlaiel]

yeah that, include is a textual replacement, so anything placed before the include is seen by all the code in the include. Not just other preprocessor stuff and pragmas but all of the other function definitions as well. There are some cases where this has legitimate use, but also is one of the main reasons why compilers can't just "compile the .h files separately and reuse that work whenever its included, automatically"

you define #import as "include but no context leaks into it" and that should on its own be enough to let the compiler just, compile that file once and reuse it wherever else its imported. That's like 95% of the benefit of what modules offered but much much simpler