On Thursday, March 6th, 2025 at 14:00, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:

> > In looking, it seems to me that making std::chrono::system_clock usable 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.

This is not really an argument. It's a statement of personal preference, and I don't think it's serious criticism of my proposal as such.
 
First, it's entirely possible for developers to do write programs like the ones you describe today.

> std::chrono::system_clock::time_point now = {};
> if (!std::is_constant_evaluated()))
> now = std::chrono::system_clock::now();

Pardon me, but this is just silly: you just wrote `auto now = std::chrono::system_clock::now();` in a more convoluted way and your example serves no purpose that I can discern.


> > 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.

I value reproducibility (and have gone to great lengths to make some of the projects I've worked on support determinstic builds) but again, I think you're stating a personal preference here.

People embed timestamps in their programs _ALL THE TIME_ and there are many legitimate reasons to do so (some *compilers* actually do it automatically for you). They just do it using the preprocessor (via __TIME__ and __DATE__ or __TIMESTAMP__) or using custom build steps or binary post-processing. I don't think providing a tool to developers that allows them to use modern C++ and the language of std::chrono to achieve those goals is a bad thing.

Generally, I think that your criticisms, interpreted more broadly, is severely limiting. I certainly agree that any tool can be misused, but I don't think that, by itself, is a good enough reason to deny use of that tool.

Imagine, for the sake of argument, that we had the ability to use `std::ifstream` at compile time to process some input file and generate an array.

We could use this functionality to parse the latest timezone database or a file describing relevant details/parameters for a family of MRI or CT machines. Heck, a more realistic example: this functionality could eliminate the resource compiler tool from the build steps; it could be done in C++.

But your position (again, interpreted broadly) basically amounts to: "NO, DON'T DO THAT." Why?