[loeg]

> You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces.

You could say that. I didn't. Bolting on some sort of module system is just a totally different scope of enhancement than my modest proposal.

> As usual, the devil lies in the detail. If you want to make pragma once robust you need to checksum files, which in the end will be slower than include guards.

That's just not true. It doesn't need to be robust against byzantine source trees and/or build systems to be defined in the C standard or to be useful. The standard can leave the concept of "the same file" implementation-defined, as it does many other concepts.

On Unix system C implementations, it is sufficient to use stat() and compare st_ino and st_dev against previously observed values for a given compilation unit. You do not need to checksum files. You especially do not need to write the specific behavior of checksumming header files into the C standard.

[kazinator]

> It doesn't need to be robust against byzantine source trees

A locally developed hack, or even a compiler extension, doesn't have to be; an ISO-standard feature should be well specified.

If something is specified in such a way that it is less robust than the #ifndef trick, then any programmer worth their salt will use the #ifndef trick.

An acceptable pragma-once would look like this:

  #pragma once 9DF9-C3D9-BDF0

Basically it should take an argument string which specifies an ID for the file, intended to be unique.

[loeg]

> ISO-standard feature should be well specified.

That claim doesn't match up with the C standard I've read. I.e., this is an "isolated demand for rigor." Are we looking at the same document? Quite a lot is underspecified or implementation defined to accommodate differences in architectures and systems.

The 2018 C standard doesn't specify whether NULL is a pointer or integer; what a null pointer's representation is; nor the representation of negative (signed) integers. The C standard defines some loose requirements around observable behavior and leaves the specific details to the implementation.

> Basically it should take an argument string which specifies an ID for the file, intended to be unique.

Or the standard could leave it up to the implementation to identify file uniqueness without this additional, incompatible argument. Like I said before, all you have to do for Unix implementations to be as robust as the stupid ifndef trick is to check st_ino and st_dev.

It's important to recognize that implementations and implementation details are distinct from the standard.

Also note that the ifndef hack is non-robust in its own way — false positive exclusions due to accidental identifier conflicts. #pragma once does not have this problem.

[kazinator]

The #ifndef trick is highly portable and has clear semantics that is under the program's control. Nobody needs a platform-specific, underspecified alternative that saves two lines of code compared to the robust, portable solution. If I am paying with nonportability, I want "bang for the buck": like faster or smaller code on the target, or detailed control of its hardware or host platform features. I don't need unspecified build machine behavior so much. I am not programming the build machine.