On Fri, 30 Aug 2024 at 02:40, Jeremy Rifkin <rifkin.jer_at_[hidden]> wrote:
>
> > 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."

Indeed. It's already hard enough to explain to users not to use
#pragma once, with all that misinformation available..

> 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.

..so the last thing we should do is put the feature into the standard,
because that will make it even harder to explain to users
not to use it, because a sizeable amount of them will not understand
those clear rules and their consequences, and will think
it's fine to use it because it's a standard feature.