OK, fair enough, I guess I left out too many assumptions. On the other hand I did not write an official RFC.
I don't agree about the atomic ptr having the same behavior at the user level. Clearly if you care enough to use atomic<T>, if it's implemented in the uArch or via an operating system synchronization primitive matters, but this is not the point.

Yes, you are right the , a hypothetical constexpr filesystem implementation should yield the same result everywhere given the same filesystem structure. I was (silently) assuming this is axiomatic, since, given this directory structure:

/a/
 b/
   c
   d
 e/
   f

I would expect the same result of a traversal on any implementation, or at least some ordering of the set of unique paths
/a/b/c
/a/b/d
/a/e/f
possibly allowing for an implementation-defined order , other than alphabetical, if that is faster.

So, given this code:

std::filesystem::path root("/a/");
std::filesystem::directory_iterator di(root);
for (auto const & entry : di)
{
  // do something with di.path();
}

it should produce the same implementation-defined list of paths (as described above) in both runtime and constexpr contexts. Seems pretty obvious.

This is a functional, but silly formalization:
# traverse the filesystem tree rooted in $(pwd)/root_dir and compute the hash sum of each file
# and the hash of the output , which will be unique for the traversal and files contents
md5deep -r -l ./root_dir | md5sum
6ad472fce87613903e6145ce920a3fdc -

that final hash sum is the invariant : any filesystem operations starting from that tree will deterministically yield the same results, (or a compile-time failure caused by an some error of the underlying filesystem)

the constexpr operations could *change* the structure of that tree (add and/or remove paths, change the contents of the file), but, given the same environment, I expect it will produce the same results, like I expect from the runtime version of std::filesystem (and frankly I don't understand what is different)

I mean, let's face it, the filesystem API is already modeled on POSIX/linux and clearly not every possible target where a standard C++ implementation can run will have block devices and sockets exposed as filesystem objects (I'm a linux guy, I'm not complaining, just pointing out the irony)

Any filesystem access errors would abort the compilation in the same way a filesystem access error will stop the compilation while files are #include-ed so it's not too much of a stretch.

This would be useful in 'low level' tooling, IDLs, build systems , dynamic test generation and the sort of automation stuff that goes on in CI/CD pipelines.

On Tue, Mar 12, 2024, at 19:30, Thiago Macieira via Std-Proposals wrote:
> On Tuesday, 12 March 2024 07:48:43 PDT Andrei Grosu via Std-Proposals wrote:
>> We have a std::atomic_is_lock_free which , in my opinion, is a kind of
>> feature gating: if the implementation of atomic<T> is not lock free (ie
>> just syntactic sugar over a mutex or something) you can tell. Again, not
>> apples to apples but frankly it is confusing from a language design pov…
>
> The behaviour of std::atomic is the same regardless of the implementation. The
> Standard does not require the implementation to be fast or that it be natively
> supported by the processor. It only describes behaviour. That's what your
> proposal needs to do: describe the behaviour that the feature should provide.
>
> That constexpr boolean informs the developer about an implementation detail
> because we have experience saying that it's possible to deploy different
> algorithms that are more efficient than a locked atomic (in particular when
> multiple atomics must be used in sequence). We have std::mutex::native_handle
> because we have experience saying that it's often useful. Similarly, we have
> throwing and non-throwing functions in std::filesystem because we have
> experience saying developers often want the non-throwing versions.
>
> We don't have experience with your feature yet to say what implementation
> details need to be provided. And of course, in a constexpr scenario, there
> shouldn't be any implementation details that are visible to the user. It
> should produce the same result, every time, for everyone.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals