I am not arguing that the *implementation* in a compiler will be simple.

As I noted in another RE on this thread, your problems go away if you are in a world where everything you do is in containers.

Indeed, if this is to be allowed for any (legacy) project it would be a nightmare (this is why this should be feature-gated in the compiler with a —Wenable_constexpr_filesystem_access or something similar), however, if I build the container and I have 100% control and audit of all the stuff that goes into it, there are no problems. There are tools and patterns to ensure cryptographic integrity of all the artifacts in the container’s filesystem (layout, libraries, headers etc).

I’m not arguing for making constexpr everything. Frankly, I don’t really like this design choice, but that’s another issue.

But for filesystem specific , apart for my specific use case, this can be used for IDLs, (parts of)?reflection , etc.

On Tue, Mar 12, 2024, at 14:11, Sebastian Wittmeier via Std-Proposals wrote:



Besides the technicalities, this proposal would really complicate dependency management for build systems.


Files could be loaded from outside the build directory.

Filepaths could depend on the contents of read files.


I am not saying that there is not any value in the idea, but a lot of considerations have to be taken in account.


E.g. limit file access to a certain folder (chroot),

provide a (black/white) list of files, which can be read in this manner to limit possible dependencies.


Are there alternatives? E.g.

 - reading files with #embed and - dynamically during compile time - choose, which embedded file to use

 - compile and afterwards run the 'build system c++ source code' by the make utility instead of running it by the compiler at compile time

 - interpreted C++ as script language


Other points:

 - security (arbitrary file access)

 - where to stop - should compile-time C++ use internet connections and have a 3D UI? Should it receive parameters from cloud-connected mobile devices with AI speech recognition? Should it be able to control robots? We need a vision, what compile time C++ is and what it is not


-----Ursprüngliche Nachricht-----
Von: Andrei Grosu via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Di 12.03.2024 12:31
Betreff: [std-proposals] constexpr support in std::filesystem API
An: std-proposals@lists.isocpp.org;
CC: Andrei Grosu <andrei_dg@mailup.net>;
The proposal is simple: constexpr support for the filesystem API.

The need comes from writing a build system in (modern) C++.
If there is support for compile-time access to the filesystem , it would be , in my opinion, the key  missing piece for a build system implemented in modern C++.
Without that you would have to depend on code generation , but with it , there is not much missing to build a fully featured build system in C++ itself.

Is this a question of compiler complexity , to enable constexpr filesystem access ? It is not clear to me if there are other factors at play.

Can anyone ‘in the know’ share some insights why it might or might not be feasable ?
Std-Proposals mailing list
Std-Proposals mailing list