In practice, it would be the job of the build system, not of the compiler to decide to recompile.   It probably would not be compatible with any build cache.   Moving it completely to the tooling would be the same as no proposal. My question was about a proposal, then we can compare to the tooling-only variant.   -----Ursprünglich Nachricht----- Von:Robin Savonen Söderholm via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 10.03.2025 10:17 Betreff:Re: [std-proposals] constexpr support for std::chrono::system_clock An:std-proposals_at_[hidden]; CC:Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>; 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] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> > Cc: Sebastian Wittmeier <wittmeier_at_[hidden] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; CC: Sebastian Wittmeier <wittmeier_at_[hidden] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> Cc: Sebastian Wittmeier <wittmeier_at_[hidden] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; CC: Tiago Freire <tmiguelf_at_[hidden] <mailto: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] <mailto:std-proposals-bounces_at_[hidden]> > on behalf of Lénárd Szolnoki via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Sent: Sunday, March 9, 2025 4:30:57 PM To: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Cc: Lénárd Szolnoki <cpp_at_[hidden] <mailto: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] <mailto: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] <mailto: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 <http://macieira.info> - thiago (AT) kde.org <http://kde.org> >>  Principal Engineer - Intel DCAI Platform & System Engineering >> >> >> >> -- >> Std-Proposals mailing list >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals       --    Std-Proposals mailing list   Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>   https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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