Date: Fri, 07 Mar 2025 08:49:17 +0000
On Fri, Mar 7, 2025 at 02:03, Tiago Freire via Std-Proposals <[std-proposals_at_[hidden]](mailto:On Fri, Mar 7, 2025 at 02:03, Tiago Freire via Std-Proposals <<a href=)> wrote:
> The simplest solution would be to just create a shell script that generates a file with the current time, let the build system call that shell script before build, and then not touch the compiler.
> That's what I do (and I don't think I'm the only one).
> Not everything needs to be a feature of the compiler.
Certainly there’s a ton of things one can do as part of the build process, with tools and scripts and whatnot, and that’s the situation a lot of us find ourselves in.
It would be nice to be able to do some of these things in C++, but I agree that not everything needs to be a feature of the compiler (or the language). I still think this is a reasonable proposal (albeit not without its issues—the ODR comments have got me thinking) and will try to refine it, but I’m ok if the consensus is that this belongs in the trash.
> As for UUID. A time stamp is not a reliable way to create a UUID, so I'm not even going to bother with that use case.
Come on now. There’s an actual RFC that describes how to do this very thing—linked in the proposal. It’s one thing if you don’t care to do this or even if you don’t think that it’s important to do be able to do it at compile time, but this particular response is just silly.
> ---------------------------------------------------------------
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jan Schultke via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Friday, March 7, 2025 7:19:32 AM
> To: std-proposals_at_lists.isocpp.org <std-proposals_at_[hidden]>
> Cc: Jan Schultke <janschultke_at_[hidden]>
> Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock
> I've got a much simpler alternative idea: we could say that every clock has a
>
>> static constinit const time_point translation_time;
>
> ... data member. There is no potential for ODR violations because you
> cannot access it during constant evaluation anyway. It's simply saying
> that you're baking the timestamp into the executable. The linker could
> still optimize it out if it's unused.
> --
> Std-Proposals mailing list
> Std-Proposals_at_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> The simplest solution would be to just create a shell script that generates a file with the current time, let the build system call that shell script before build, and then not touch the compiler.
> That's what I do (and I don't think I'm the only one).
> Not everything needs to be a feature of the compiler.
Certainly there’s a ton of things one can do as part of the build process, with tools and scripts and whatnot, and that’s the situation a lot of us find ourselves in.
It would be nice to be able to do some of these things in C++, but I agree that not everything needs to be a feature of the compiler (or the language). I still think this is a reasonable proposal (albeit not without its issues—the ODR comments have got me thinking) and will try to refine it, but I’m ok if the consensus is that this belongs in the trash.
> As for UUID. A time stamp is not a reliable way to create a UUID, so I'm not even going to bother with that use case.
Come on now. There’s an actual RFC that describes how to do this very thing—linked in the proposal. It’s one thing if you don’t care to do this or even if you don’t think that it’s important to do be able to do it at compile time, but this particular response is just silly.
> ---------------------------------------------------------------
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jan Schultke via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Friday, March 7, 2025 7:19:32 AM
> To: std-proposals_at_lists.isocpp.org <std-proposals_at_[hidden]>
> Cc: Jan Schultke <janschultke_at_[hidden]>
> Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock
> I've got a much simpler alternative idea: we could say that every clock has a
>
>> static constinit const time_point translation_time;
>
> ... data member. There is no potential for ODR violations because you
> cannot access it during constant evaluation anyway. It's simply saying
> that you're baking the timestamp into the executable. The linker could
> still optimize it out if it's unused.
> --
> Std-Proposals mailing list
> Std-Proposals_at_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-03-07 08:49:26