To be fair:   How much different is it in power from a C23 #embed?   Both feature that certain files, the ones which the implementation allows, can be fully (binarily) read at compile time.   Differences:  - the filepath can be created at runtime -> better hiding of the file read read; C23 probably supports macros for the filepath?  - the contents can be processed by constexpr functions -> probably the same can be achieved by mixing C23 with C++ constexpr  - the files could be read several times -> Denial of Service build; a long build can probably be achieved by other ways   -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 12.03.2024 15:06 Betreff:Re: [std-proposals] constexpr support in std::filesystem API An:Andrei Grosu <andrei_dg_at_[hidden]>; std-proposals_at_[hidden]; Jonathan Wakely <cxx_at_[hidden]>; CC:Tiago Freire <tmiguelf_at_[hidden]>; > That is a straw man argument. > If you had amazon.com as your home it should not have passed code review and merge request, along with whatever security audit tooling your build system should run anyways. Its not a strawman. A standard is not just for you, it is for everyone. Including people who do open-source projects, and whose working environment isn't as closely monitored as you may think. Even in your closed environment I can think of extremely easy ways to hide malicious constexpr payload to take over your entire company and you wouldn't even notice in a PR. And that's just 5 minutes thinking about the problem, imagine what a motivated malicious actor with enough time and resources could achieve. And why would I want to do this to begin with? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals