Hi Filip!   Include files are built to be inserted anywhere and multiple times. Even if they are often not used that way. Each time different symbols can be #defined beforehand (by the including file), so the include files could conditionally do different things each time. So compared to modules, we are on a low level and early compilation phase.   What constitutes the same file is complicated. Many paths in the file system can go to the same file: There are multiple include paths given (environment or compiler command line or pragmas), there are relative directories, disk drives, symbolic and hard links. More involved build systems cache include files outside their original path. Sometimes the same include file exists several times in different directories and it is meant to be treated as the same file. Sometimes the same looking (byte-identical) include file has to be inserted multiple times, as it was copied within sub-projects, e.g. some config.h by the same developer, included by other library headers in turn.   As long as there is no registry or database with metadata serving the include files, the best way to identify them, if necessary, in general and in a portable and safe way is with an identifier inside the file. That is, what also include guards do.   There was the idea to create something nicer looking akin to   #includeonce identifier   It has only small improvements over include guards and would not be compatible to old preprocessors. Especially since many C++ IDEs and editors directly recognize and support include guards.     There was the alternative idea to standardize #pragma once, perhaps even with that name, and keep it implementation-defined.   But with it there would be standard-compliant include files that are only partially portable between implementations or build systems.     There is the 3rd way to keep as it is. Whoever lives with the shortcomings of #pragma once can do so, even if it is not standardized. For truly portable and safe headers, include guards with well-chosen guard define names should be preferred. A standardization of #pragma once would water down that recommendation.     Some 4th people say, modules are the future anyway. Let's not put the effort into improving include files.     Between that directions there was no majority so far for any successful proposal.     And currently you seem to bring nothing new to the discussion. You can try to create a proposal. But you would have to bring those factions together.   So a likely successful proposal would not be simple and would have to analyze and delve into all those mentioned issues in full detail for all platforms.   I get the impression you have not even started to address the main relevant issues of this topic, which makes it difficult to find a quick solution or even one with broad majority support.   -----Ursprüngliche Nachricht----- Von:Filip via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 24.03.2025 11:20 Betreff:Re: [std-proposals] #pragma once safer alternative An:std-proposals_at_[hidden]; CC:Filip <fph2137_at_[hidden]>; Bo Persson <bo_at_[hidden]>; std-proposals_at_[hidden]; My 2 cents here would be that like you mentioned before: neither include guard nor pragma is a standard solution. This means that we either rely on a bug prone hack or non standard solution to obtain the effect of:  “Include / import the file only once.”  Which seems like it’s a missing feature, it’s such a common use case that it should be standardized. Also not changing other file but stating: #include once “header.hpp” Is preferred in my opinion since you might not own the other file maybe it’s a part of some other repo.  P.S. Maybe worth mentioning is the fact that I never want to include a file more than once.  P.S.S. Should we not standardize include once since we have a non standard option available everywhere? Shouldn’t we standardize everything that’s useful and thus lower the chance for bugs?  Cheers, Filip Wiadomość napisana przez Bo Persson via Std-Proposals <std-proposals_at_[hidden]> w dniu 24 mar 2025, o godz. 08:11: On 2025-03-24 at 02:51, Muhammad via Std-Proposals wrote: Last thing about #include once, As with all preprocessing directive it get affected with the conditional #if family of preprocessing directive, for example: //d.hpp #ifdef D_HPP #   include once #endif The file d.hpp will get included every time it appears in the #include until the macro D_HPP gets defined. What if D_HPP gets undefined again in another header? There are tiny corner cases all around! You also have the problem of how you find the header: "A preprocessing directive of the form   # include < h-char-sequence > new-line searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined." (https://eel.is/c++draft/cpp.include#2) There are two "implementation-defined" right here. Later it continues: "The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined. The implementation shall provide unique mappings for sequences consisting of one or more nondigits or digits ([lex.name]) followed by a period (.) and a single nondigit. The first character shall not be a digit. The implementation may ignore distinctions of alphabetical case." So d.HPP and D.hpp might be different files? Or not? I have worked on mainframes (IBM z/OS) where the file system doesn't have directories or extensions on file names. Another corner case (where d.hpp might be HPP(D) on disk). -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals