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>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>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).
Tom.
From: Tom Honermann <tom@honermann.net>
Sent: Saturday, March 8, 2025 6:20:05 AM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Jonathan Wakely <cxx@kayari.org>; Tiago Freire <tmiguelf@hotmail.com>; std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>; Proposals C++ <std-proposals@lists.isocpp.org>
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@lists.isocpp.org> 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.--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals