Reading the paper now, I'd suggest two changes:
* For the unqualified form, not restricting it to require a
content-for-content check, but refer to files with the same identity, then
leave that implementation-defined (provide the suggestions from above in
the paper, but discourage use of a simple path-based solution).
* For the qualified form, don't treat it as using the identifier for
`#ifdef`, but instead state
> If a file that is being substituted by an `#include` directive contains a
directive of the form `#pragma once IDENTIFIER`, the `#include` directive
expands to a single whitespace character instead of the token contents of
the file if it has previously evaluated an `#include` directive that
referred to a preprocessing unit that contains the same directive with the
same identifier.

Otherwise, other `#define`s can conflict with it.

I also don't think the paper addresses the use of `_Pragma("once")`. For
consistency with `#pragma`, I might recommend that `_Pragma` operate
identically when used for the standard once directives.


On Tue, 27 Aug 2024 at 12:52, Gašper Ažman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> My project doesn't "have problems".
>
> When you're compiling on a compute-farm and you're mounting immutable
> object stores for your builds because otherwise your build literally
> consumes 10x the I/O, then your local include of #include "siblingheader.h"
> has a fundamentally different include path than my #include
> "3p/yourlib/siblingheader.h", and the compiler will get the 3p one through
> a sandbox (a standard bazel feature) and the sibling through a direct
> directory scan. It's a matter of how you do a syscall.
>
> This is an incredibly engineered build system, which is *still* a far cry
> from being as complex as google's codefs, but please don't tell me how
> using fuse to save on I/O is somehow unreasonable and I should not be using
> _features c++ literally guarantees me because they are standard_.
>
> Some of us spend 7 or 8 digits a year on compute and I/O for builds.
> Literally, don't try to teach me my job.
>
> On Tue, Aug 27, 2024 at 5:45 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
>> I agree that pragma once should mean same file and not file with same
>> bits.
>>
>> But I disagree on everything else.
>> I used pragma once exclusively on all my libraries quite successfully,
>> they are well organized and no such confusion could occur by design, "as a
>> well orchestrated build should".
>>
>> If you are in a situation where this causes problems, either by having
>> multiple copies of the same library or by using symbolic or hard links,
>> and they all end up on the same include stack. Well... then don't do that
>> then! Seems like a you problem.
>> I'm not trying to dunk on a "serious project" with a "quite amateurish
>> build execution", I'm pretty sure there are legacy reasons as to why your
>> project ended up in this awkward situation, my advice is just don't use it
>> for your project then.
>>
>> There's no reason why everyone else has to code like its 1990 just
>> because your project got problems.
>>
>>
>> My 2c
>>
>> ------------------------------
>> *From:* Gašper Ažman <gasper.azman_at_[hidden]>
>> *Sent:* Tuesday, August 27, 2024 5:34:42 PM
>> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
>> *Cc:* Tiago Freire <tmiguelf_at_[hidden]>
>> *Subject:* Re: [std-proposals] Revising #pragma once
>>
>> #pragma once is unimplementable.
>>
>> That's because it doesn't mean "don't include a file with the same
>> bytes", it means "don't include the same file". And the second you have the
>> same file accessible through two separate fuse mountpoints, no amount of
>> stat() will help you identify it's the same file.
>>
>> We hit this in our build-farms all the time, I had to write tooling to
>> kill it.
>>
>> Don't make me explain this in-committee, again.
>>
>> On Tue, Aug 27, 2024 at 4:32 PM Tiago Freire via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> I like pragma once, should be standardized, but the problem is in the
>>> details of the wording.
>>>
>>> I know that the paper acknowledges that some compiler issues a warning
>>> if they appear in the source file, and that the paper doesn't advocate for
>>> the warning either way. But the note seems to suggest otherwise.
>>> It would be best if the standard had no notion of what a source file is,
>>> and you should remove the note that a compiler could issue a warning, let
>>> that just be a vendor detail.
>>>
>>> The description of how the directive should behave isn't the best,
>>> describing in in terms of an ifdef block is not good.
>>>
>>>
>>> ------------------------------
>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on
>>> behalf of Jeremy Rifkin via Std-Proposals <
>>> std-proposals_at_[hidden]>
>>> *Sent:* Tuesday, August 27, 2024 4:01:08 PM
>>> *To:* Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
>>> *Cc:* Jeremy Rifkin <rifkin.jer_at_[hidden]>
>>> *Subject:* [std-proposals] Revising #pragma once
>>>
>>> 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
>>> .
>>>
>>> Cheers,
>>> Jeremy
>>> --
>>> 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
>