Hi Andrei,   I was quoting "The proposal is simple: constexpr support for the filesystem API."   If one (at least for an initial proposal) limits the filesystem IO to certain resources (e.g. similar as #embed (C23); it searches for resources in an 'implementation-defined manner'), an implementation could easily define that    - without compiler-switches, no resource is accessible  - with compiler-switches one can select a subdirectory as (ch)root, where all resources have to be in   That would make things much easier.   -> Some implementations could choose not to make resources available at all. -> Otherwise dependencies are limited to the chosen subdirectory. -> For a container based build, one could select the overall container root as resource root path.   -----Ursprüngliche Nachricht----- Von:Andrei Grosu <andrei_dg_at_[hidden]> Gesendet:Di 12.03.2024 13:24 Betreff:Re: [std-proposals] constexpr support in std::filesystem API An:Std-Proposals <std-proposals_at_[hidden]>; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; 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: Simple?   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_at_[hidden]> Gesendet: Di 12.03.2024 12:31 Betreff: [std-proposals] constexpr support in std::filesystem API An: std-proposals_at_[hidden]; CC: Andrei Grosu <andrei_dg_at_[hidden]>; 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_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals --  Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals