Note that this only partially helps with a subset of the problem (and modules as proposed don't fix the issue, they just help a bit more): CPP still needs to make separate passes for each translation unit, for example. I'd recommend reading the link I put in my original post...

Which breaks #includes written to be included multiple times and provide different outcomes based on defined macros.

C based toolchains are just broken.

If a file is intended to be read multiple times with different results, then obviously you don't want to prevent it being read twice. However, we were talking about preventing the hit from reading a file twice unnecessarily. The quoted text says it doesn't bother rescanning if the macro is still defined. How do you get a different outcome from scanning the same file with the same define? Can you provide an example where this breaks things?

Yes, it's an optimization, it'll just make the common case (include guard) faster, without breaking anything.

How do you force the file to be re-read multiple times when the outcome is not idempotent?

I do not understand why you are arguing about this.

There are two scenarios: in one you want to prevent a file from being read multiple times because it wastes resources (and in some sad cases, might cause issues with redefinition). In this case, you use the include guards and the compiler can do a trick to optimize out unneeded scanning.

You have this other hypothetical scenario in which you purposefully want a file to be read multiple times, with a different outcome (this kind of trickery isn't usually possible at all in other languages with module system so it is funny to argue about C being broken). Now I don't think this is a common scenario or even a good one to be in, but it is possible. The solution is simple: don't try to prevent the file from being read multiple times. Why would you try to prevent it, if it is meant to be read multiple times?

You are arguing that a door is broken because you cannot walk in through it if you close the door. Don't close the door if you want to walk in...

Because it is an optimization that relies on well behaved developers and we all know how good such assumptions end, specially in big teams with high attrition.

As I read this, if the compiler determines that (with the #define set) the file is effectively empty, it knows it can just check the #define next time rather than re-reading. Without this optimization, you get the same result slower. It doesn't depend on well-behaved anything to get a result just as correct as without the optimization.

With the single possible exception of a file that changes on disk between the multiple includes in the same build step. That is not a situation I have ever encountered and I am not at all sure it is supported and there aren't a bazillion other things that would break it in any given compiler chain (certainly at least line directives would be wrong, but that's arguably minor I guess).

It doesn't rely on anything. It's a correct optimization that does not change any behavior at all. It only speeds things up.

Just #include it again and it will work like expected.

This preprocessor optimization is only for the case where include guards block off the entire #include file. Ex:

    #ifndef INCLUDE_FOO_H
    #define INCLUDE_FOO_H

    #endif

When the preprocessor sees that, it marks it off and never reads the file again (Unless you were to #undef INCLUDE_FOO_H, but that's an extremely unlikely scenario since it's likely to break your code). If you want to be able to include a file multiple times, just don't use include guards. Even without this optimization your idea still wouldn't work if you placed include guards in your #include file. All this does is speed up preprocessing when we already know that the file has no new lines to be added.

I am not talking about include guards, rather macros that affect the outcome of specific file.

It is not a very clean way of coding, but there are many enterprise developers that provide files without include guards and include them multiple times.

An example would be generic data structures in C done with macros.

    #define DATA_TYPE int
    #define DATA_NAME intList_t
    #include <list.h>

    typedef struct { /* ... */ } Node;

    #define DATA_TYPE Node
    #define DATA_NAME nodeList_t
    #include <list.h>

It's pretty unlikely that list.h would have a trivial include guard, so I don't see how the above optimization would break it. An include guard in list.h would prevent you from using it properly with or without the optimization.

Not when you #undef it. That was just a possible example.

If list.h has no include guard, it gets included with or without this optimization. If it has an include guard and you #undef it, then it gets included again with or without this optimization. If you it has an include guard and you do not #undef it, it does not get included again, with or without this optimization.

In no case does this optimization change the code emitted.