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]> 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]> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>