On 3/10/25 5:16 AM, Tiago Freire via Std-Proposals wrote:
> AW: [std-proposals] constexpr support for <a
> class="moz-txt-link-freetext"
> href="std::chrono::system_clock">std::chrono::system_clock</a>
>
> Ps. Now that I think about it, what happens to build cache? What if
> now() is generated by the compiler does it mean that every single
> source file needs to be rebuild every single time (because it could
> change at every time you compile it)?
>
> When you build it again it is technically a new build time, right?
>
How is that different from the status quo given the existence of
__TIME__, __DATE__, and __FILE__ (for relocatable builds)?

Tom.

> *From:*Tiago Freire <tmiguelf_at_[hidden]>
> *Sent:* Monday, March 10, 2025 10:13 AM
> *To:* std-proposals_at_[hidden]
> *Cc:* Sebastian Wittmeier <wittmeier_at_[hidden]>
> *Subject:* RE: [std-proposals] constexpr support for
> std::chrono::system_clock
>
> 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]> *On
> Behalf Of *Sebastian Wittmeier via Std-Proposals
> *Sent:* Monday, March 10, 2025 9:52 AM
> *To:* std-proposals <std-proposals_at_[hidden]>
> *Cc:* Sebastian Wittmeier <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]>
> *Gesendet:* Mo 10.03.2025 08:35
> *Betreff:* RE: [std-proposals] constexpr support for
> std::chrono::system_clock
> *An:* std-proposals_at_[hidden];
> *CC:* Sebastian Wittmeier <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]> *On
> Behalf Of *Sebastian Wittmeier via Std-Proposals
> *Sent:* Monday, March 10, 2025 12:05 AM
> *To:* std-proposals_at_[hidden]
> *Cc:* Sebastian Wittmeier <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]>
> *Gesendet:* Mo 10.03.2025 00:02
> *Betreff:* Re: [std-proposals] constexpr support for
> std::chrono::system_clock
> *An:* std-proposals_at_[hidden];
> *CC:* Tiago Freire <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]>
> on behalf of Lénárd Szolnoki via Std-Proposals
> <std-proposals_at_[hidden]>
> *Sent:* Sunday, March 9, 2025 4:30:57 PM
> *To:* std-proposals_at_[hidden]
> <std-proposals_at_[hidden]>
> *Cc:* Lénárd Szolnoki <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]> 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]> 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 - thiago (AT)
> kde.org
> >> Principal Engineer - Intel DCAI Platform & System Engineering
> >>
> >>
> >>
> >> --
> >> Std-Proposals mailing list
> >> Std-Proposals_at_[hidden]
> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
>
> Std-Proposals mailing list
>
> Std-Proposals_at_[hidden]
>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>