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>
    constexprautoeven_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>
    constexprauto*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]>
> *Sent:* Saturday, March 8, 2025 6:20:05 AM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Jonathan Wakely <cxx_at_[hidden]>; Tiago Freire
> <tmiguelf_at_[hidden]>; std-proposals_at_[hidden]
> <std-proposals_at_[hidden]>; Proposals C++
> <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]> 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
>
>