Would the proposal here be to make constexpr std::chrono give the
invocation time or some fixed now time for the whole compilation?

I'm just imagining:

consteval void who_needs_fast_compilation_anyway() {
    auto start = std::chrono::system_clock::now();
    while(std::chrono::system_clock::now() < start +
std::chrono::minutes(1)) {}
}

Cheers,
Jeremy

On Fri, Mar 7, 2025 at 5:06 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Strictly speaking, the result of constexpr functions depends on compiler
> environment even now:
>
>
>
> constexpr bool status() {
>
>
>
> #ifdef FLAG
>
> return true;
>
> #else
>
> return false;
>
> #endif
>
>
>
> }
>
>
>
> You can modify the output of status() with -DFLAG
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Fr 07.03.2025 23:35
> *Betreff:* Re: [std-proposals] constexpr support for
> std::chrono::system_clock
> *An:* std-proposals_at_[hidden]; Jonathan Wakely <cxx_at_[hidden]>;
> *CC:* Tiago Freire <tmiguelf_at_[hidden]>; C++ Proposals <
> std-proposals_at_[hidden]>;
> 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]> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>