Let us make a different example, why distinguishing by file contents is bad:   --- preprocessor_tools.h --- #pragma once #define STRINGIFY ... #define CONCAT ...   --- cleanup.h --- #ifdef STRINGIFY #undef STRINGIFY #endif #ifdef CONCAT #undef CONCAT #endif   --- lib1maininclude.h --- #include "a.h" // may include preprocessor_tools.h #include "b.h" // may include preprocessor_tools.h, prevented by #pragma once - intended! #include "cleanup.h" // do not bleed symbols     A library1 and a library2 happen to use the same preprocessor_tools.h. Within each of those libraries #pragma once is used to prevent redefinition.   But if both libraries are included, the second library misses out on the already undefined symbol definitions.     -----Ursprüngliche Nachricht----- Von:Jeremy Rifkin <rifkin.jer_at_[hidden]> Gesendet:Di 27.08.2024 19:08 Betreff:Re: [std-proposals] Revising #pragma once An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; > I.e. a.h could prevent b.h from being included? Or patha/a.h couild prevent pathb/b.h?  Correct, it can. While this may feel weird initially, it is true to the concept of single inclusion.  > That could lead to interdependencies between different libraries.  I don’t immediately see how. I might be missing something though.  > There are some preprocessor tricks, where you define macros and then include files, which use the defined macros.  Such cases, relying on multiple inclusion, would have to mot use #pragma once/traditional include guards.  >  But as patha/definealla.h and pathb/defineallb.h are the same They are at least one byte different in your example (A vs B).  Cheers, Jeremy   On Tue, Aug 27, 2024 at 11:47 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: So the proposed #pragma once would only care for file contents, not for path or filename? I.e. a.h could prevent b.h from being included? Or patha/a.h couild prevent pathb/b.h?   That could lead to interdependencies between different libraries.   There are some preprocessor tricks, where you define macros and then include files, which use the defined macros. Some of the include files could accidentally (e.g. taken from the same original source) be the same between different projects.     E.g. (simple example)   ------------- patha/definealla.h and pathb/defineallb.h ------------- #pragma once   #define basename A #include "usebasename.h" #undef basename   #define basename B #include "usebasename.h"     #undef basename   ---------------------------------------------------------------------------------------   patha/usebasename.h and pathb/usebasename.h would be different depending on the needs of libarary a and library b. But as patha/definealla.h and pathb/defineallb.h are the same and both use #pragma once, the latter would not be included, although they have differents paths and different names!           -----Ursprüngliche Nachricht----- Von:Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Gesendet:Di 27.08.2024 18:36 Betreff:Re: [std-proposals] Revising #pragma once An:Gašper Ažman <gasper.azman_at_[hidden] <mailto:gasper.azman_at_[hidden]> >; CC:Jeremy Rifkin <rifkin.jer_at_[hidden] <mailto:rifkin.jer_at_[hidden]> >; std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> ; This paper proposes #pragma once mean don’t #include the same contents again. Unlike GCC which will perform multiple inclusion if mtime differs. This paper leaves open the possibility of implementations doing their own fast path checks of inode, stat, etc., but ultimately the file contents are what matter.  Jeremy -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals