On 3/9/25 7:02 PM, Tiago Freire via Std-Proposals wrote:
> 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?
>
That would depend on the details of the proposal to add constexpr to the
declaration of now(). If it also adds constexpr to the declarations of
the time_point related functions, then sure.

In C++26, following the recent adoption of P1967R14 (#embed - a
scannable, tooling-friendly binary resource inclusion mechanism)
<https://wg21.link/p1967r14>, a constexpr variant of now() (limited to a
single point in time) can be implemented on Linux using #embed to read
from /proc/driver/rtc.

Tom.

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