It's called a strawman argument. You come up with an implementation that doesn't work, point at it and say that it doesn't work. But nobody is advocating for the implementation you have happened to choose. At least I'm not.

And then completely overlook implementations that would actually work.
I keep saying, you don't need this, you don't need that, but you keep insisting on over-defining an implementation to solve problems that are not problems, to accommodate workflows that don't exist.


You went out of your way to give it the least charitable interpretation so that you could shoot it down.


-----Original Message-----
From: Ville Voutilainen <ville.voutilainen_at_gmail.com>
Sent: Monday, September 2, 2024 2:04 PM
To: Tiago Freire <tmiguelf_at_hotmail.com>
Cc: std-proposals_at_lists.isocpp.org; Tom Honermann <tom_at_honermann.net>
Subject: Re: [std-proposals] Revising #pragma once

On Mon, 2 Sept 2024 at 13:34, Tiago Freire <tmiguelf_at_hotmail.com> wrote:
>
> > An #include has no need to tell two files apart. Could you please explain what you're talking about here?
>
> It needs to find a file, not just any file, it needs to find a specific file. Which has an identity, it doesn't go about looking at inodes to figure if the file I specified is the one I actually intended.
> You don't go about "hey what happens if network files recycle inodes, include doesn't work".
> That include files work based of file paths alone is not a cause for confusion, and so shouldn't pragma once.

Well, Jonathan and Gasper covered most of this. That explanation or the comparisons in it don't make any sense. Sure, an #include "foo.h" won't open a "randomlychosen.txt".
But other than that, yes, it opens whichever file the include paths at that point point to, so it might not be the same "foo.h" everywhere. And that's just fine.
Include guards will prevent 99% of mishaps.

#pragma once is not like that *at all*. When it is encountered in a header, we don't just look at whatever files relevant to that build context, we look at previously-opened files, and try to match exactly them for sameness, which is a definition with different trade-offs.

I don't get how this "is not a cause for confusion". Yeah, there's nothing confusing as such about a case where a header is included multiple times due to a failing pragmaonce match, your code just doesn't compile. But the reasons for that are rather inexplicable. And the cases where a pragmaonce failing in the other direction causes files not to be included are more inexplicable still; look at Tom's horror story for splendid example of that.

Cool, don't look at inodes, don't look at mtimes, don't look at anything. The end result is more failing builds, for users other than you. No vendor is going to ship that sort of crap, and none of them are going to speak in favor of standardizing such a beast.
And neither are any people who are aware of and have sympathy for the use cases that don't work with it. A relatively safe prediction is that that's enough people to sink the proposal.