The module system doesn’t have side effects on inclusion, whereas headers do.

So again, maybe if you have a smaller, cleaner or dependency free codebase, then it’s not an issue.

But in any codebase of major scale or legacy, headers can introduce several issues that aren’t possible with the module interface.

The side-effects are merely the rules of C++, that you already know by virtue of writing C++.

I feel like you’re talking past any of the caveats I’ve mentioned twice. I have no interest in belabouring the point with someone who’s clearly ignoring what’s being written. Have a good day.

You're really burying the lede here.

Headers are literal copy paste, and are entirely different. Anyone who has ever had to define WIN32_LEAN_AND_MEAN knows that there's _way_ more going on here.

This exactly, thank you. Sometimes you can’t untangle the defines in another header and they infect your own.

Modules are a nice barrier to guard against side effects.

Yes, the number of times I've had a `LoadLibrary` function name conflict with `windows.h`'s `A`/`W` suffix-switching or had to deal with X11's `#define Status int` "typedef" mucking with completely unrelated code is…sad.

Just don't include those in headers.

That's not possible. Windows.h is a requirement for anyone working on Windows. Various standard library implementations make use of macros to implement debug-only assertions, or bounds checks in containers.

Don't include it in headers = only include it in a .cpp file.

Because `void*` to pass `HANDLE` around is better how? Maybe if you're able to hermetically seal off platform-specific bits, but usually you'll have two parts that want to talk about Windows API types across their call boundaries…

It's called encapsulation.

Sure, but I also prefer talking directly about what you're talking about though. If you have some Windows implementations that need to talk to each other, I'd rather they use HANDLE and HMODULE than "void* winkwinknudgenudge" style things. Hopefully users don't need to include these headers directly (but sometimes they do), but it's still something you need to consider in the APIs and such because while the header might say LoadLibrary, the caller is going to need to include windows.h and deal with the #define anyways.

any interaction with the win32 api should be hidden within your library.

Surely you want your code to be portable to begin with?

It can be portable and still want to expose native information. SDL2 is probably something we can all agree is portable, but this still exists: https://wiki.libsdl.org/SDL2/SDL_SysWMmsg