There is existing precedent in std::source_location::current(); it yields a different result for each source location it is called from. These different results do not produce ODR violations within inline functions or const/inline variable initializers (unlike __FILE__) because the token sequence isn’t changed. Some special accommodations were made for invocations of consteval functions in default arguments to support idiomatic usage.

Tom.

> On Mar 7, 2025, at 5:35 PM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> But there's very good reason to not allow this.
> constexpr function shouldn't be allowed to give different results when called with the same arguments (or no arguments in this case).
> There's no proper model to make sense of this. And we should not start opening exceptions.
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Friday, March 7, 2025 7:31:17 PM
> To: Jonathan Wakely <cxx_at_[hidden]>
> Cc: Nikolaos D. Bougalis <nikb_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]>
> Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock
>
> On Thursday, March 6th, 2025 at 17:10, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
> > > Even if this functionality were added, it would not affect reproducible builds in _any_ way, _unless the developers of the software chose to use it_! Given that it is largely incompatible with reproducible/deterministic builds, why would they?
> >
> >
> > The people writing the code might not be the ones compiling it. Linux distros want reproducible builds, and it's a problem if that's impossible because some software they want to package insists on using clocks and there's no way to override the time (the way there is for __TIME__).
>
> Fair point, and to be clear, I have no objection to (a) extending -Wdate-time and equivalent options to produce a warning if the functionality is used; (b) offering a standardized way to override the system clock and supply the time explicitly; and (c) even offering a standardized way to disable the functionality entirely, so the code produces an error..
>
>
> > I assure you that reproducible builds are important.
>
> Thank you, but I don't think I ever argued that they were not important. Over the past 25 years I had to implement determinstic builds more than once (sometimes for regulatory reasons, others because it made sense given the project's goals) and at least once I had to go to great lengths to get them to work. So I am very aware of both how important they are and what a pain point they can be to get right. I assure you that I am not out here looking to twist the standard so as to make them harder in any way.
>
> At the same time, I don't think that we should use reproducible builds as an excuse to not have this functionality anymore than I think we should disallow bakeries from baking fresh bread because I am doing keto and the aroma of fresh-baked goods is PAINFUL.
>
> Anyways, as I said in a different post, a number of legitimate concerns, apart from determinism, have been raised, some of which I had not considered. I'll give some more thought to the proposal and try to address as many of the issues as I can going forward.
>
> Best regards,
>
> Nik Bougalis
>
> --
> 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