Perhaps this should be combined with other possible functions returning information about the compile-time environment.   Reading environment variables, reading files, interacting with the user.   If this functionality can be programmed in C++ consistent with runtime code and libraries accessing the information, but be optional and separated from other (reproducible) constexpr code?   -----Ursprüngliche Nachricht----- Von:Robin Savonen Söderholm via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 07.03.2025 12:39 Betreff:Re: [std-proposals] constexpr support for std::chrono::system_clock An:std-proposals_at_[hidden]; CC:Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>; I honestly prefer the idea of having this functionality in a separate function (if we are to support this at all). First it is semantically something entirely different from "system_clock::now()": now() is the "human readable" time that the running system is reporting, while the proposal is about "some time" reported by the compiler running on the _compiling_ system. Secondly: I want to constexpr everything that I can, but I in general don't want to have unreproducible builds: if I by mistake add constexpr/consteval to a function that uses system_clock::now(), I *want* to get a compilation error if I try to compile-time evaluate that expression. Uniformity is one thing, but accidentally get something when I wanted something else is bad. // Robin On Fri, Mar 7, 2025, 12:30 Paul Keir via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Sounds good. While benchmarking compile-time performance, I added a constexpr timing function to Clang. It's true, as the proposal's Section 4.2 states, that "Different compilers may evaluate the function at different times in the compilation process", but surprising timing changes on a single compiler can still be revealing; and with larger granularity and program sizes, timing comparisons between compilers can also be considered. As was said by Howard Hinnant and others, __TIME__ already opened the box; and as well as its lack of UTC support, it only has a granularity of seconds. Of course this proposal also supports uniformity: removing another set of `constexpr if` statements when porting a library for compile-time use. I also like Thiago Macieira's suggestions (Thu 6 Mar, 23:16) regarding having low expectations on the time value returned.  -- Paul On Thu, 6 Mar 2025 at 21:44, Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Hello everyone,  I've been doing a lot of constexpr-related stuff lately, and one of the things that I needed but didn't really have access to was a Clock​. In looking, it seems to me that making std::chrono::system_clock​ usable in constexpr contexts is pretty simple and invokes marking one function as constexpr​: now​. Obviously, there's a little more to it than this, in the sense that it will require some additional support by the compiler that the standard library implementers can use to get the current time.  Adding this functionality would give programmers an actual usable clock at compile time, that uses the already familiar language of std::chrono​ and enable (indeed, make trivial!) a number of use cases, some of which are currently impossible, including the timing the compilation of constexpr code to identify potential bottlenecks. Less exotic use cases include the ability to generate time-based UUIDs at compile time, to seed random number generators at compile time, potentially warn when old code is compiled (not that there's anything wrong with that!)  This is my first solo proposal, and I'd be very interested in hearing what everyone thinks.  Best regards,  Nik Bougalis       -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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 -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals