This breaks when you have pre-compiled dependencies. It would also force
everything to rebuild if it so much as mentions the "compile time now". And
please, don't overload the "system_clock::now" with this function, that
should _only_ mean "time from my running system". Make a
"compiler_clock::now()" if you really need this feature..

// Robin

On Mon, Mar 10, 2025, 10:13 Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> This is how I think it should ideally work:
>
> 1. Generate that as a pre-compilation stage.
>
> 2. The compiler receives those as a constant that never changes during the
> compilation process, even across different TUs.
>
> Preferably Tooling, not compiler features. Agreement between what *ALL*
> compilation units see, not just what 1 unit sees. Consistent regardless of
> compiler vendor.
>
> Implying that a constexpr now() (if it exists) would always give the same
> result no matter when and how it is used in a translation unit, probably
> set externally (so that all TUs can agree) which leads to the conclusion
> that the compilation time is generated in a previous stage outside the
> compiler, not by the compiler.
>
>
>
>
>
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf
> Of *Sebastian Wittmeier via Std-Proposals
> *Sent:* Monday, March 10, 2025 9:52 AM
> *To:* std-proposals <std-proposals_at_[hidden]>
> *Cc:* Sebastian Wittmeier <wittmeier_at_[hidden]>
> *Subject:* Re: [std-proposals] constexpr support for
> std::chrono::system_clock
>
>
>
> Let's have some use cases:
>
>
>
> I want to print the date and time my program was compiled.
>
> I want to have a modern time zone aware C++ interface.
>
> I want the printout be formatted (processed) at compile time.
>
>
>
> What changes in the proposal would make this possible without going into
> problems with
>
> - non-reproducible constexpr: We need just one point of time for the
> program (what about multiple TU? Each TU gets its own now() 'instance'?)
>
> - reproducible builds: compiler flags?
>
> -----Ursprüngliche Nachricht-----
> *Von:* Tiago Freire <tmiguelf_at_[hidden]>
> *Gesendet:* Mo 10.03.2025 08:35
> *Betreff:* RE: [std-proposals] constexpr support for
> std::chrono::system_clock
> *An:* std-proposals_at_[hidden];
> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>
> I would expect not to have to think about if the conditional branching is
> decided when the function is evaluated or if a decision needs to be taken
> every single time it is called in a constexpr context.
>
> I don’t want to have to think about if my conditions hold true or change
> based on whatever else the compiler decided it has done before somewhere
> else unrelated.
>
> I don’t want to think what conditionally evaluated branch was active
> before and that it could be different now, and what does that mean at
> runtime vs compile time.
>
>
>
> While __TIME__ has the benefit of at least being an in-place replacement
> at pre-processing stages, now() would not be that.
>
> And while “std::source_location” is concerning, it has at least some sort
> of consistency that can be reasoned about.
>
> This breaks everything.
>
> Think of template expansion, think of unevaluated branches, think of how
> many more rules you would need to enforce in order for different compiler
> vendors to produce consistent results when asked (a <= b).
>
> And then realize that the motivation for this can be done with much better
> results if you don’t touch the compiler.
>
> Non-deterministic constexpr functions are evil, they are a terrible idea.
> Please don’t do this.
>
>
>
>
>
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf
> Of *Sebastian Wittmeier via Std-Proposals
> *Sent:* Monday, March 10, 2025 12:05 AM
> *To:* std-proposals_at_[hidden]
> *Cc:* Sebastian Wittmeier <wittmeier_at_[hidden]>
> *Subject:* Re: [std-proposals] constexpr support for
> std::chrono::system_clock
>
>
>
> 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_at_[hidden]>
> *Gesendet:* Mo 10.03.2025 00:02
> *Betreff:* Re: [std-proposals] constexpr support for
> std::chrono::system_clock
> *An:* std-proposals_at_[hidden];
> *CC:* Tiago Freire <tmiguelf_at_[hidden]>;
>
> 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_at_[hidden]> on behalf
> of Lénárd Szolnoki via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Sunday, March 9, 2025 4:30:57 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Lénárd Szolnoki <cpp_at_[hidden]>
> *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_at_[hidden]> 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_at_[hidden]> 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_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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>