On 8/30/24 02:24, Jeremy Rifkin via Std-Proposals wrote:
>>> People are using #pragma once, standard or not. Standardizing it would
>>> give people clearer expectations about when it is and is not ok to
>>> use.
>
>> I wonder how standardizing it does that. And how not standardizing it doesn't.
>
> While I have explained a lot of this in my draft paper, I am happy to
> elaborate. Currently there is no clear set of semantics for #pragma
> once, it's simply a "vibe" regarding single-inclusion. The primary
> concern about #pragma once is portability because every implementation
> is free to do it slightly differently, and in practice they each have
> taken a very different approach. It is currently the case that the
> vast majority of users have no idea exactly when it may or may not
> fail to do what they expect.
>
> The point of a standard is to provide clear guidelines about what it
> means. If for example, the standard guarantees that symbolic links and
> hard links are handled, then the user can be confident their #pragma
> once code will do what they want unless 1. there could be multiple
> unique copies of the header or 2. they have a setup like Gasper's with
> multiple mount points. In such a case, they should use traditional
> include guards. Libraries in general should use traditional include
> guards, for example.

You keep missing the point it isn't "they" (the people who compile the
code) who are necessarily using `#pragma once`. Blessing `#pragma once`
by putting it in the standard basically tells more developers to use it,
meaning that more of the code that currently compiles in elaborate
environments will fail to compile after the standardization.

And I don't think you have presented a sufficient motivation for using
`#pragma once` over the include guards beyond that compilers support it,
in one form or another. Yes, `#pragma once` relieves you from having to
invent an include guard name (which may happen automatically by the
IDE), but that is not enough of a benefit when it breaks compilation for
someone.