Timing the compiler just right wasn't what I was going for.

What I was going for is the transitive nature of "allowed to give different results".

Could that example be allowed to compile, i.e. could an indirect constexpr function produce different values, or is it required to give the exact same value everything single time?

Is it transitive? Does it have to be evaluated every single time it appears? Or does the compiler have to remember every single answer?

Because depending on the answer I'm going to use that to create a different gadget to break the language.

________________________________
From: Tom Honermann <tom_at_[hidden]>
Sent: Sunday, March 9, 2025 3:24:55 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_hotmail.com>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock

On 3/8/25 6:05 AM, Tiago Freire via Std-Proposals wrote:
Oh no...
It's a bit concerning that this was adopted in this way, but what is being asked breaks things in ways that perhaps source_location wouldn't.

Here's my question:

constexpr auto indirect_get_time()
{
 return now();
}

constexpr auto a = indirect_get_time();
constexpr auto b = indirect_get_time();

static_assert(a != b);


Can this create a valid program?

You probably realize where I am going with this.

If you don't like that the compiler can reject your source code unless you time the compiler invocation just right, then I would suggest not writing that code.

std::source_location can be employed to make a program ill-formed if an empty line is added. https://godbolt.org/z/4svrf4KEx.

#include <source_location>
constexpr auto even_line_only = std::source_location::current().line();
static_assert(even_line_only % 2 == 0);

It can also be used to interfere with location independence of otherwise reproducible builds. https://godbolt.org/z/E9YWv7TEs.

#include <source_location>
constexpr auto *file_path = std::source_location::current().file_name();
static_assert(file_path[0] == '/');
static_assert(file_path[1] == 'a');
static_assert(file_path[2] == 'p');
static_assert(file_path[3] == 'p');

As others have said, all features can be abused.

Is there evidence of std::source_location causing problems for reproducible builds that isn't sufficiently addressed by options like -ffile-prefix-map, -fdebug-prefix-map, -fmacro-prefix-map, -Wdate-time, and the SOURCE_DATE_EPOCH environment variable? I'm not aware of any, but I'm not an expert in reproducible builds either.

What evidence exists that indicates that a constexpr std::chrono::system_clock::now() would be employed in problematic ways in practice and that wouldn't be sufficiently addressed by options like those above (particularly SOURCE_DATE_EPOCH)? I acknowledge that the ability to compute durations during constant evaluation would pose a new scenario that is not possible with __TIME__ today. Is that significant? My expectation is that such computed durations would be transient and likely used in conjunction with facilities like those proposed by P2758 (Emitting messages at compile time)<https://wg21.link/p2758>.

Tom.


________________________________

From: Tom Honermann <tom_at_[hidden]><mailto:tom_at_honermann.net>
Sent: Saturday, March 8, 2025 6:20:05 AM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_kayari.org><mailto:cxx_at_[hidden]>; Tiago Freire <tmiguelf_at_[hidden]><mailto:tmiguelf_at_[hidden]>; std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]>; Proposals C++ <std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock

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]><mailto: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_lists.isocpp.org><mailto:std-proposals-bounces_at_[hidden]> on behalf of Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]>
Sent: Friday, March 7, 2025 7:31:17 PM
To: Jonathan Wakely <cxx_at_[hidden]><mailto:cxx_at_[hidden]>
Cc: Nikolaos D. Bougalis <nikb_at_[hidden]><mailto:nikb_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]><mailto: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]><mailto: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]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

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