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
--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@lists.isocpp.org> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Monday, March 10, 2025 9:52 AM
To: std-proposals <std-proposals@lists.isocpp.org>
Cc: Sebastian Wittmeier <wittmeier@projectalpha.org>
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@hotmail.com>
Gesendet: Mo 10.03.2025 08:35
Betreff: RE: [std-proposals] constexpr support for std::chrono::system_clock
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>;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@lists.isocpp.org> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Monday, March 10, 2025 12:05 AM
To: std-proposals@lists.isocpp.org
Cc: Sebastian Wittmeier <wittmeier@projectalpha.org>
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@lists.isocpp.org>
Gesendet: Mo 10.03.2025 00:02
Betreff: Re: [std-proposals] constexpr support for std::chrono::system_clock
An: std-proposals@lists.isocpp.org;
CC: Tiago Freire <tmiguelf@hotmail.com>;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?
--Std-Proposals mailing listStd-Proposals@lists.isocpp.orghttps://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals