Niall Douglas wrote:

> Please find attached draft 2 of proposed normative wording for D1030R4
> std::filesystem::path_view.

The suggested use pattern is

int open_file(path_view path)
{
    path_view::c_str<> p(path);
    return ::open(p.buffer, O_RDONLY);
}

but the name c_str implies

int open_file(path_view path)
{
    return ::open(path.c_str(), O_RDONLY);
}

which is both more convenient and less error-prone because it avoids the
need for another name (`p` in the above).

It's not hard to make the latter work. path_view::c_str() can be a function
returning c_str_result, which is the current c_str struct by another name,
and c_str_result can have a conversion to T const*.

In addition, while (the current) c_str allows both the allocation and the
deallocation to be customized, allocation is overridden by passing a
function object to the constructor, whereas deallocation is overriden by a
Deleter template parameter (which can have no state.)

It would be more symmetric and more consistent with the rest of the standard
library if both were customized via the use of an Allocator. (Which could
also allow the use of memory_resource*.)