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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>