I thought that I needed to make a decision before presenting 1 of 2 types of gadgets that broke things in different ways, but after thinking about it.

extern uint32_t g0;

constexpr auto g1 = now();

constexpr uint32_t foo(uint32_t var)

{

  if constexpr ( now() - g1 > nanoseconds(3) )

 {

return var + 1; 

 }

else

{

 return var - 1;

}

}

uint32_t const g2 = foo(g0);

Is this valid?

That would depend on the details of the proposal to add constexpr to the declaration of now(). If it also adds constexpr to the declarations of the time_point related functions, then sure.

In C++26, following the recent adoption of P1967R14 (#embed - a scannable, tooling-friendly binary resource inclusion mechanism), a constexpr variant of now() (limited to a single point in time) can be implemented on Linux using #embed to read from /proc/driver/rtc.

Tom.

---

From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Lénárd Szolnoki via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Sunday, March 9, 2025 4:30:57 PM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Lénárd Szolnoki <cpp@lenardszolnoki.com>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock

On 7 March 2025 01:14:17 GMT, Jeremy Rifkin via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>>> In looking, it seems to me that making
>>> std::chrono::system_clockusable in
>>> constexpr contexts is pretty simple and invokes marking one function as
>>> constexpr: now.
>>
>> Please don't.
>
>+1

+1

This is an ODR footgun among other concerns about reproducible builds. The following is instant ODR violation, if appears in multiple TUs and the clock is not faked:

inline constexpr auto x = std::chrono::system_clock::now();

>
>Also this strikes me as a good way to violate ODR.
>
>Cheers,
>Jeremy
>
>On Mar 6 2025, at 4:00 pm, Thiago Macieira via Std-Proposals
><std-proposals@lists.isocpp.org> wrote:
>
>> On Thursday, 6 March 2025 13:43:47 Pacific Standard Time Nikolaos D.
>> Bougalis
>> via Std-Proposals wrote:
>>> In looking, it seems to me that making
>>> std::chrono::system_clockusable in
>>> constexpr contexts is pretty simple and invokes marking one function as
>>> constexpr: now.
>>
>> Please don't. Your software should not depend on the time it was
>> compiled at
>> and should not change depending on that.
>>
>>  std::chrono::system_clock::time_point now = {};
>>  if (!std::is_constant_evaluated()))
>>     now = std::chrono::system_clock::now();
>>
>>> 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!)
>>
>> Please make your software reproducible: it should be bitwise exactly
>> identical
>> if it is compiled by the same compiler.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>  Principal Engineer - Intel DCAI Platform & System Engineering
>>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals@lists.isocpp.org
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals