On Saturday, 8 March 2025 21:09:39 Pacific Daylight Time Tom Honermann wrote:
> Sure, that is a possibility, but it also makes the feature unusable for some
> use cases. An implementation could also have now() function like a counter
> and return a time point that is incremented by one second each time it is
> called.

I'd argue that use-case should not exist in the first place. It's the wrong
tool.

The interpretation of constexpr code may have no resemblance of how real
execution looks like. That is, the the evaluation order of expressions, and
thus the time they are evaluated, may not be that of the program order. The
compiler has far more information that the CPU ever will on dependencies, so
it could scan ahead and evaluate the time-getting calls very quickly.

More importantly, the constexpr evaluation is not the way to obtain timing of
the compilation of constexpr code. Very likely, the AST just gets flattened
into an evaluation list and then executed very quickly. This would mean the
first time evaluation is after the parsing and flattening of the AST, and the
last is before the emission of any code.

> My question remains the same though. Would the ability to compute durations
> be used in practice in such a way that it would interfere with reproducible
> builds? What would idiomatic use look like?

Yes. The build should not depend on which machine it is built on and whether I
was watching YouTube in the background.

Besides, std::system_clock does not have a requirement to be monotonic or to
move forward at all. The standard couldn't offer that to constexpr code because
it can't require that of the system_clock that is inside the compiler itself.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering