I’m going to be a bit ranty here.

People... we are going too far of the rails. I don't think the point is to change current behavior, most compilers that matter already have it.
The only thing that it would change if at all would be for some obscure compiler that does not have it to have to pick an implementation.

All it has to do is to say that #pragma once precludes the #include directive from evaluating the file if that file is the same. That is it!

Whatever that means for that system it’s an implementation detail, left for the compiler vendor as an exercise.
Should 2 hard links to the same thing be considered "the same file", as far as I'm concerned, any answer you can possibly give here is a valid perspective, and you will never get a consensus debating this.
If one compiler looks at the time to resolve a file difference and the other does not, as far as I am concerned, they are both standard compliant.
It shouldn't be made a requirement that it needs to look at the time (it doesn’t even make sense), it may not even be a requirement that it may be a file in a drive or a file system.
An include directive requires a "what" and a pragma once says that "if the what is this just skip it".


I'm going to be perfectly honest with you, if you are doing things right, these “differences” in behavior they don’t matter at all, they never did.
The shear volume of cross-platform projects that use pragma once exclusively (despite the fact that they work with different tools), say that it doesn’t matter. They don’t seam to mind that the behavior is different, like at all.
I have personally never heard of a project that had “use pragma once” as part of the codding standard ever revert back to using “include guards”, while the opposite is a process that I have over-seen countless times.

You are looking at the time of the file? Why?
If your project even as much as needs to distinguish based on symbolic links as far as I'm concerned it has serious issues with build hygiene.
You are copying files around? Why?
And if your build fails as a consequence, you kind of deserve it. Maybe pragma once is not for you.

As far as I’m concerned not being able to parse included files more than once should be the default behavior, because invariably, every single time, that’s what you want, always. I have 0 instances where that has ever been otherwise.
I mean, I have worked with code where it had this “tricky header file” where you would “have to include more than once”, and the second time around “it was doing a tricky thing changed behavior that somebody thought it was smart”.
It’s not smart, it’s pretentious and there’s no reason it has to work that way, and that is fixable. Just fix that and move on, stop making life harder for everyone else!

We can pretend all day that all this corner cases and weird behavior is normal, it ain’t! If your build does that you have failed to do it properly!
Stop wearing those foot guns!

Include directives are kind of broken, I think we can all agree with that, it is bad as it is that I have to write WARTS (and that’s what they are, they are warts) on my header files just to make something that should have been simple work, don’t make me have to be creative about it.
Just standardize pragma once, it ain’t perfect (perfect would be nothing), but at least it is less warts to deal with, and it doesn’t need to be complicated at all.



________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, August 27, 2024 7:57:56 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] Revising #pragma once


Let us make a different example, why distinguishing by file contents is bad:



--- preprocessor_tools.h ---

#pragma once

#define STRINGIFY ...

#define CONCAT ...



--- cleanup.h ---

#ifdef STRINGIFY

#undef STRINGIFY

#endif

#ifdef CONCAT

#undef CONCAT

#endif



--- lib1maininclude.h ---

#include "a.h" // may include preprocessor_tools.h

#include "b.h" // may include preprocessor_tools.h, prevented by #pragma once - intended!

#include "cleanup.h" // do not bleed symbols





A library1 and a library2 happen to use the same preprocessor_tools.h.

Within each of those libraries #pragma once is used to prevent redefinition.



But if both libraries are included, the second library misses out on the already undefined symbol definitions.




-----Ursprüngliche Nachricht-----
Von: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Gesendet: Di 27.08.2024 19:08
Betreff: Re: [std-proposals] Revising #pragma once
An: std-proposals_at_lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]>;
> I.e. a.h could prevent b.h from being included? Or patha/a.h couild prevent pathb/b.h?

Correct, it can. While this may feel weird initially, it is true to the concept of single inclusion.

> That could lead to interdependencies between different libraries.

I don’t immediately see how. I might be missing something though.

> There are some preprocessor tricks, where you define macros and then include files, which use the defined macros.

Such cases, relying on multiple inclusion, would have to mot use #pragma once/traditional include guards.

> But as patha/definealla.h and pathb/defineallb.h are the same


They are at least one byte different in your example (A vs B).

Cheers,
Jeremy


On Tue, Aug 27, 2024 at 11:47 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

So the proposed #pragma once would only care for file contents, not for path or filename?

I.e. a.h could prevent b.h from being included? Or patha/a.h couild prevent pathb/b.h?



That could lead to interdependencies between different libraries.



There are some preprocessor tricks, where you define macros and then include files, which use the defined macros.

Some of the include files could accidentally (e.g. taken from the same original source) be the same between different projects.




E.g. (simple example)



------------- patha/definealla.h and pathb/defineallb.h -------------

#pragma once



#define basename A

#include "usebasename.h"

#undef basename



#define basename B

#include "usebasename.h"





#undef basename



---------------------------------------------------------------------------------------



patha/usebasename.h and pathb/usebasename.h would be different depending on the needs of libarary a and library b.

But as patha/definealla.h and pathb/defineallb.h are the same and both use #pragma once, the latter would not be included, although they have differents paths and different names!










-----Ursprüngliche Nachricht-----
Von: Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Gesendet: Di 27.08.2024 18:36
Betreff: Re: [std-proposals] Revising #pragma once
An: Gašper Ažman <gasper.azman_at_[hidden]<mailto:gasper.azman_at_[hidden]>>;
CC: Jeremy Rifkin <rifkin.jer_at_[hidden]<mailto:rifkin.jer_at_[hidden]>>; std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
This paper proposes #pragma once mean don’t #include the same contents again. Unlike GCC which will perform multiple inclusion if mtime differs. This paper leaves open the possibility of implementations doing their own fast path checks of inode, stat, etc., but ultimately the file contents are what matter.

Jeremy
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]pp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals