This is a good point. I guess there’s a question of how far beyond
traditional include guards #pragma once should attempt to go. This is an
example of an identifier collision as well as a content collision , which
can only be resolved with filesystem or path help. But trying to resolve
this would pessimize other cases like multiple copies of the same library
header file. I am wondering if maybe the answer here is that a main header
like this just shouldn’t have include guards in the first place.

Jeremy

On Tue, Aug 27, 2024 at 13:38 Jonas Christen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I think relative includes really would be a problem if #pragma once was
> just looking at a files content and not its path or anything else at all.
> It's not too uncommon to have a "main" header for just including other
> headers (which can have pretty common names).
> So something like this (somewhat similar to Sebastians example earlier)
> would already fail:
>
> // library_a/app.hpp
> #pragma once
> namespace library_a{ constexpr int execute(){ return 1; } }
>
> // library_b/app.hpp
> #pragma once
> namespace library_b{ constexpr int execute(){ return 2; } }
>
> // library_a/library_a.hpp (comments not part of the header)
> // include guards with same behavior as pragma once based only on file
> content would have
> #ifndef FILE_HASH_ABC
> #define FILE_HASH_ABC
> #include "./app.hpp"
> #include "./util.hpp"
> #endif
>
> // library_b/library_b.hpp (comments not part of the header)
> // include guards with same behavior as pragma once based only on file
> content would have
> #ifndef FILE_HASH_ABC
> #define FILE_HASH_ABC
> #include "./app.hpp"
> #include "./util.hpp"
> #endif
>
> // main.cpp
> #include <string>
> #include <iostream>
> #include "./library_a/library_a.hpp"
> #include "./library_b/library_b.hpp"
>
> int main(int argc, char* argv[]){
> if(argc < 2)
> return -1;
>
> if(std::string{argv[1]} == "library_a")
> std::cout << library_a::execute() << "\n";
> else if(std::string{argv[1]} == "library_b")
> std::cout << library_b::execute() << "\n";
>
> // library_b::execute() is never declared
> // because library_a.hpp and library_b.hpp are identical
> // which leads to library_b/app.hpp never being included
>
> return 0;
> }
>
> On Tue, 27 Aug 2024 at 20:35, Jeremy Rifkin via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> > Yes, it does. It makes the behavior different from what is expected by
>> majority of users. And is prone to subtle errors, if different headers
>> happen to match in contents.
>>
>> The current behavior expected by the majority of users is hard to argue
>> about because the semantics aren’t spelled out anywhere and every
>> implementation does it differently. #pragma once represents the loose
>> concept of single inclusion, and the semantics proposed here are not prone
>> to the subtle errors of mtimes happening to match, symbolic or hard links
>> not being handled well, certain filesystem mount behavior, or multiple
>> copies of the same header being unintentionally included more than once
>> (e.g. if a library header is copied around).
>>
>> There are few to no cases where you would want to include a file with the
>> same exact contents with #pragma once multiple times. The only case
>> presented here has to do with including a header of only macros then
>> undefining everything then redefining. Such use probably shouldn’t be using
>> an include guard in the first place and it’s important to note that
>> traditional include guards might cause problems there too.
>>
>> Jeremy
>>
>> On Tue, Aug 27, 2024 at 12:28 Andrey Semashev via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On 8/27/24 20:14, Jeremy Rifkin wrote:
>>> > Does using contents for #pragma once break any practical or plausible
>>> > uses of #pragma once? Does it have any clear downsides?
>>>
>>> Yes, it does. It makes the behavior different from what is expected by
>>> majority of users. And is prone to subtle errors, if different headers
>>> happen to match in contents.
>>>
>>> > I don’t think does. It should only make things more robust and
>>> portable.
>>> >
>>> > Jeremy
>>> >
>>> > On Tue, Aug 27, 2024 at 12:07 Andrey Semashev via Std-Proposals
>>> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]
>>> >>
>>> > wrote:
>>> >
>>> > On 8/27/24 17:01, Jeremy Rifkin via Std-Proposals wrote:
>>> > > Hi,
>>> > > I have drafted a proposal for standardizing #pragma once. This
>>> has
>>> > been
>>> > > previously proposed a few years ago and I recognize that on top
>>> of
>>> > being
>>> > > difficult to standardize, existing opinions on this topic may
>>> > render the
>>> > > paper dead on arrival. However, due to its widespread nature and
>>> > > concerns about portability contributing to it not being used
>>> more I
>>> > > think it's worth revisiting. I have uploaded the first draft at:
>>> > >
>>> >
>>> https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html
>>> <
>>> https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html>
>>> <
>>> https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html
>>> <
>>> https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html
>>> >>.
>>> >
>>> > I think, using file contents for `#pragma once` is wrong and
>>> should not
>>> > be standardized. The intended effect of `#pragma once` has always
>>> been
>>> > to avoid including *the same header* twice, not *the same content*.
>>> >
>>> > --
>>> > Std-Proposals mailing list
>>> > Std-Proposals_at_[hidden] <mailto:
>>> Std-Proposals_at_[hidden]>
>>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>> > <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
>>>
>> --
>> 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
>