> Right. Any by not standardizing this misfeature, we can explain to users that it shouldn't be used anywhere, as it's non-standard for good reasons

I respect your standpoint. I think it's worth looking at the status
quo today and advice on google regarding the topic:

Let's look at the prevailing advice today, from the first google
results on the topic:
https://thamara.dev/posts/pragma-once-vs-header-guards/:
> "In my opinion, it’s still perfectly fine to take on the usage of #pragma once regardless of its issues in specific scenarios such as a smaller codebase or when teaching."
https://stackoverflow.com/questions/27649946/when-to-use-include-guards-or-pragma-once-c:
> The second answer cautions against #pragma once, a highly upvoted comment on that answer reads "Also the portability claim is bogus, since #pragma once is supported by every single relevant compiler out there."
- https://luckyresistor.me/2019/07/13/why-its-time-to-use-pragma-once/
> "I recommend using #pragma once instead of old macro-based header guards. It will reduce the number of preprocessor macros and prevent potential and hard to find compilation problems."
- https://stackoverflow.com/questions/5776910/what-does-pragma-once-mean-in-c
> "I see some people in the comment section advocate for using guards instead of #pragma once. This makes little to no sense in 2023 and beyond unless you are targeting some special compiler that you know does not support #pragma once."
> "Today's best practice is to use only #pragma once and don't bother with guards at all."

Whether you or I like it doesn't really matter, nor does its status as
a feature or "misfeature."

The status quo is people are using it because it just simply works -
at least the vast majority of the time. Does it create a mess for
some? Maybe. I'm just saying we can make things better by providing
clear rules.

Jeremy

On Thu, Aug 29, 2024 at 6:30 PM Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Fri, 30 Aug 2024 at 02:24, Jeremy Rifkin <rifkin.jer_at_[hidden]> wrote:
> > 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.
>
> Right. Any by not standardizing this misfeature, we can explain to
> users that it shouldn't
> be used anywhere, as it's non-standard for good reasons. Which is the
> status quo for
> quite many of us.