Niall Douglas wrote:
> >> If we insisted on Allocators, we would force a needless extra dynamic
> >> memory allocation and memory copy solely because we insisted on
> >> Allocators.
> >
> > I don't see why.
>
> My personal primary motivation are functions such as
> https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-rtlansistringtounicodestring
> or
> https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-rtlunicodestringtoansistring
> which are much more efficient if you let them allocate the destination
> buffer for you.

OK, I see where you are coming from. However, I'm not quite sure that this
affects the allocator/deleter question. At the moment, you do this

    path_view::c_str<> tmp( path );

to get the default allocation behavior, and you do this

    path_view::c_str<char, my_deleter> tmp( path, my_alloc_fn [,
my_deleter{...}] );

to override it.

In the allocator-based version, you'd do this

    path_view::c_str<> tmp( path );

to get the default behavior, and

    path_view::c_str<char, my_allocator> tmp( path [, my_alloc] );

to override it.

There's no reason for the default allocator used in the first case to not be
able to deallocate (and allocate but that's not going to be called) using
the NT kernel API.

(path_view::zero_terminated omitted for brevity.)

If you add a memory_resource* overload with nullptr meaning "default", the
second case can become

    path_view::c_str<> tmp( path, my_resource );

at the cost of one additional pointer in c_str<>. Given that sizeof(c_str<>)
is 1K+, that's probably not going to be an issue.

In fact with the right deduction guides these can turn into

    path_view::c_str tmp( path );

    path_view::c_str tmp( path, my_alloc_fn, my_deleter );

for R4 and

    path_view::c_str tmp( path );

    path_view::c_str tmp( path, my_alloc );

    path_view::c_str tmp( path, my_resource );

for the hypothetical allocator-taking interface.