> On Mar 8, 2025, at 10:23 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Saturday, 8 March 2025 18:24:48 Pacific Standard Time Tom Honermann via Std-
> Proposals wrote:
>> What evidence exists that indicates that a constexpr
>> std::chrono::system_clock::now() would be employed in problematic ways
>> in practice and that wouldn't be sufficiently addressed by options like
>> those above (particularly SOURCE_DATE_EPOCH)? I acknowledge that the
>> ability to compute durations during constant evaluation would pose a new
>> scenario that is not possible with __TIME__ today. Is that significant?
>
> The compiler implementers in the list can probably speak more about this, but
> I suspect the implementation would return the same time stamp for ALL calls in
> the compilation, matching that of __TIME__. That is, if you tried to time the
> execution, you'd find out that it was instantaneous (or shorter than the
> minimum granularity).

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.

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?

Tom.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals