What do you expect?

 

Even if it is valid, it would not be functional.

 

As was pointed out, constexpr functions are not necessarily evaluated in any order.

 

So it makes no sense to measure a time duration.

 

So even if now() changes its value, the second now() could be evaluated before the first.

 

Or possibly the compiler could cache the value from a previous compilation run and use the cached value for either or both.

 

As now() is not constexpr at the current standard, the code could be made valid or not.

 

It probably would only make sense, if now() always returns the same value for each translation unit. Any other result would tempt to make time measurements.

 


 

-----Ursprüngliche Nachricht-----
Von: Tiago Freire via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mo 10.03.2025 00:02
Betreff: Re: [std-proposals] constexpr support for std::chrono::system_clock
An: std-proposals@lists.isocpp.org;
CC: Tiago Freire <tmiguelf@hotmail.com>;
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?
 
 
 
 
 

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