If this were done, I’d expect it to be a new function, maybe named compile_time(). And I would certainly not assume it enables timing compilation time, that’s not necessarily how a compiler works evaluating its constexpr expressions. Of course some compiler option probably disables it or makes it return a defined value or such, for those who need reproducible builds.



From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Nikolaos D. Bougalis via Std-Proposals
Sent: Thursday, March 6, 2025 13:44
To: std-proposals_at_[hidden]
Cc: Nikolaos D. Bougalis <nikb_at_[hidden]>
Subject: [std-proposals] constexpr support for std::chrono::system_clock

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