Oh no...
It's a bit concerning that this was adopted in this way, but what is being asked breaks things in ways that perhaps source_location wouldn't.

Here's my question:

constexpr auto indirect_get_time()
{
 return now();
}

constexpr auto a = indirect_get_time();
constexpr auto b = indirect_get_time();

static_assert(a != b);


Can this create a valid program?

You probably realize where I am going with this.


________________________________

From: Tom Honermann <tom_at_[hidden]t>
Sent: Saturday, March 8, 2025 6:20:05 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_[hidden]>; Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Proposals C++ <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock

There is existing precedent in std::source_location::current(); it yields a different result for each source location it is called from. These different results do not produce ODR violations within inline functions or const/inline variable initializers (unlike __FILE__) because the token sequence isn’t changed. Some special accommodations were made for invocations of consteval functions in default arguments to support idiomatic usage.

Tom.

On Mar 7, 2025, at 5:35 PM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:


But there's very good reason to not allow this.
constexpr function shouldn't be allowed to give different results when called with the same arguments (or no arguments in this case).
There's no proper model to make sense of this. And we should not start opening exceptions.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden].org> on behalf of Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, March 7, 2025 7:31:17 PM
To: Jonathan Wakely <cxx_at_[hidden]>
Cc: Nikolaos D. Bougalis <nikb_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock

On Thursday, March 6th, 2025 at 17:10, Jonathan Wakely <cxx_at_[hidden]> wrote:


> > Even if this functionality were added, it would not affect reproducible builds in _any_ way, _unless the developers of the software chose to use it_! Given that it is largely incompatible with reproducible/deterministic builds, why would they?
>
>
> The people writing the code might not be the ones compiling it. Linux distros want reproducible builds, and it's a problem if that's impossible because some software they want to package insists on using clocks and there's no way to override the time (the way there is for __TIME__).

Fair point, and to be clear, I have no objection to (a) extending -Wdate-time and equivalent options to produce a warning if the functionality is used; (b) offering a standardized way to override the system clock and supply the time explicitly; and (c) even offering a standardized way to disable the functionality entirely, so the code produces an error..


> I assure you that reproducible builds are important.

Thank you, but I don't think I ever argued that they were not important. Over the past 25 years I had to implement determinstic builds more than once (sometimes for regulatory reasons, others because it made sense given the project's goals) and at least once I had to go to great lengths to get them to work. So I am very aware of both how important they are and what a pain point they can be to get right. I assure you that I am not out here looking to twist the standard so as to make them harder in any way.

At the same time, I don't think that we should use reproducible builds as an excuse to not have this functionality anymore than I think we should disallow bakeries from baking fresh bread because I am doing keto and the aroma of fresh-baked goods is PAINFUL.

Anyways, as I said in a different post, a number of legitimate concerns, apart from determinism, have been raised, some of which I had not considered. I'll give some more thought to the proposal and try to address as many of the issues as I can going forward.

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