> 1. One would think that reproduciblr builds are something everyone should strive for.

Yes, and constexpr file access is the opposite of that. Imagine having source code that would only compile if you had amazon.com as your home page of your default web browser?
How fun

What you are asking isn't an optional feature, but to create a giant security vulnerability.


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Andrei Grosu via Std-Proposals
Sent: Tuesday, March 12, 2024 2:46 PM
To: Jonathan Wakely <cxx_at_kayari.org>; std-proposals_at_lists.isocpp.org
Cc: Andrei Grosu <andrei_dg_at_mailup.net>
Subject: Re: [std-proposals] constexpr support in std::filesystem API

OK,
First I am just arguing here for the sake of the discussion, just to make it clear.

1. One would think that reproduciblr builds are something everyone should strive for.

2. Regarding the optionally enabled stuff in the standard, there is a giant, gaping precedence for this: exceptions. RTTI can be conditionally disabled at compile time. I have a compiler flag that disables parts of the standard c++ . Why would it be oknfor exeptions/rtti but not for something like constexpr filesystem ? ( or anything else for that matter ).

As what is relevant to *me* or not, the argument is moot. Just because there are legacy code bases with 10s of millions of lines of spaghetty C++98 code that can’t be upgraded to modern C++ for a variety of reasons it doesn’t mean that the rest of us can’t use advanced features of the language that could be conditionally enabled or disabled for specific needs.

I’m sorry I really don’t understand the argument . What is *appropriate* for the standard ?
Move semantics ? How many legacy code bases were converted to use move semantics after 2011 …?
How many were converted to use sane, type safe patters such as Optional, Variant etc …?
Does the standard *mandate* usage of such features ?
Threads are not safe to use if your team does not understand systems programming, multithreading etc and could lead to security issues. Should std::thread be also disabled ?
If my project never used any threads, could I had shot down proposals for a standardiation of threading back in C++11 ?

wrote:
> On Tue, 12 Mar 2024 at 12:35, Andrei Grosu via Std-Proposals
> <std-proposals_at_[hidden].org> wrote:
>>
>> Yes, you are right, but I do not want to standardize a build system.
>>
>> I wanted a constexpr filesystem (and file io) that could be optionally enabled.
>
> Then it's not appropriate for the standard.
>
> Your suggestion is that the problems aren't significant because *you*
> follow particular rules that mean they're not problems. But when
> putting something in the standard we can't enforce that everybody
> builds in reproducible containers nor that they use an optional
> compiler flag to enable something the standard says is a required part
> of C++.
>
>
>>
>> I don’t want to make this about build systems , but about constexpr filesystem api. I was simply pointing out that most of the problems raised by REs here can be adressed, not in a theoretical way but in a practical way ( I was working on containerized, secured, reproducible builds in containers quite a long time ago).
>>
>>
>> On Tue, Mar 12, 2024, at 14:25, Andrey Semashev via Std-Proposals wrote:
>> > On 3/12/24 15:03, Andrei Grosu via Std-Proposals wrote:
>> >> You are right, I will return with a complete example to explain
>> >> the problem, but , unrelated to my specific use case, the problems
>> >> you and someone else raised are non-problems from my perspective:
>> >>
>> >> All builds are made in containers that I define and are by
>> >> definition reproducible builds. There are pretty strong guarantees
>> >> that a container-based reproducible build system guarantees the
>> >> exact same environment, including the filesystem . Similarly, any
>> >> security concers of Marcin are moot : any changes will be local to that container.
>> >> I agree that maybe containerized, reproducible build systems are
>> >> not the norm in the c++ world, but still.
>> >>
>> >> But thanks for the input.
>> >
>> > Build environment is out of scope of the C++ standard. Whatever
>> > language feature you propose, must work well in any reasonable build environment.
>> >
>> >> On Tue, Mar 12, 2024, at 13:49, Matthew Taylor wrote:
>> >>> Granted, I'm not as familiar as some to the specific needs of
>> >>> writing a build system, but could you elaborate further on
>> >>> specifically what you want and specifically why it would be an
>> >>> improvement? Just adding constexpr to filesystem operations seems
>> >>> like it has a large area of confusion for the obvious reason of
>> >>> there being no guarantee that a program will be compiled and run
>> >>> on the same filesystem (as well as a few other reasons of varying obviousness).
>> >>>
>> >>>
>> >>> Are you looking for a facility like #embed, to directly embed
>> >>> file data into your source code? Or are you thinking of the
>> >>> possibility of more complex file manipulation performed by the compiler?
>> >>
>> >>
>> >
>> > --
>> > Std-Proposals mailing list
>> > Std-Proposals_at_lists.isocpp.org
>> > 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
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals