ODR violations would depend on how it would be used inside of a header. As long as it is a TU local entity (mostly internal linkage), there should be no direct problem? https://en.cppreference.com/w/cpp/language/tu_local     -----Ursprüngliche Nachricht----- Von:Tiago Freire <tmiguelf_at_[hidden]> Gesendet:Mo 10.03.2025 11:23 Betreff:RE: [std-proposals] constexpr support for std::chrono::system_clock An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; In that case, it wouldn’t have the constexpr problems I’ve highlighted. At least within a single TU there wouldn’t be any visible side-effects regarding how the compiler decided to perform the evaluation. It would be no different than __TIME__ (in regard to consistency, not result)   It would still however have ODR problems. Can’t be used in a header, only in a source file. And if you want the compile-time, I generally see this feature in build/version information, you will probably want a single version of it, (such that your about window doesn’t show a different compile time from your properties). Which means if used, the right way to use it would be to only feature in a single source file trough the entire compilation (that composes the binary file), and exposed to other units as an unknown extern.   Baking it in a header at a pre-build stage, at least only the code seeing the header would change, could also use the data in a constexpr context instead of not knowing what the value it would take because it is an extern.     From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Sebastian Wittmeier via Std-Proposals Sent: Monday, March 10, 2025 10:46 AM To: std-proposals_at_[hidden] Cc: Sebastian Wittmeier <wittmeier_at_[hidden]> Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock   And if we make it a TU specific compile time? Which can be accessed from constexpr code?   -----Ursprüngliche Nachricht----- Von: Robin Savonen Söderholm via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Gesendet: Mo 10.03.2025 10:33 Betreff: Re: [std-proposals] constexpr support for std::chrono::system_clock An: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> ; CC: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden] <mailto:robinsavonensoderholm_at_[hidden]> >; Yes of course. What I meant was that going the extra mile to make sure that all _currently compiling_ TU:s have the same "compile time clock value" would be meaningless unless you recompiled _everything_ every time you needed to recompile _anything_. If you really want all TU:s to have the same "compile time now" it could be better to provide it as an "extern const"-variable that the linker could provide, but then we can't really do anything meaningful with it if we want to embed the value inside a pre-built library instead. I second the opinion that "I don't think this is a good idea"...   // Robin   On Mon, Mar 10, 2025, 10:25 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: 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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; CC: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden] <mailto: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] <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