I think often people limit to much their thinking to "what can the compiler do", without realizing that there are other ways to do things.

It has been alluded already but some problems are better solved by your build system instead, or better yet other tools that you can attach to it.
Yes, there's the compiler, the linker, on some compilers the resource compressor, the program database generator, some frameworks use meta-code generators, resource transformers, shader compilers, package generators, etc...

Getting the time of your build should be 1 step in your build system, not a compiler feature.



________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, March 6, 2025 11:42:25 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Nikolaos D. Bougalis <nikb_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock

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?

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals