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

Jeremy

On Thu, Aug 29, 2024 at 6:07 PM Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Fri, 30 Aug 2024 at 02:05, Jeremy Rifkin <rifkin.jer_at_[hidden]> wrote:
> >
> > > All those poor developers need to do is use include guards. That's
> > > demonstrably not an unreasonable burden.
> >
> > > It's high time this proposal is nuked, yet again. I'll happily do that
> > > in the committee if need be, but I'd prefer not wasting time on it
> > > there.
> >
> > 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.