On Wed, 21 Oct 2020 at 19:13, Jonathan Wakely via Lib-Ext
<lib-ext_at_[hidden]> wrote:
>> A non obvious goal of path views is that they are standalone C++
>> friendly i.e. allocators may not be available at all. I'll be stating
>> that in the preamble to draft 3.
>>
>> Would directly supporting memory_resource& but not STL allocators
>> directly work for you? Again I do want to emphasise it is trivially easy
>> for users to wrap up a STL allocator into either the existing mechanism,
>> or a memory_resource& for that matter.
>>
>
> Since we have no way in the standard (only in the Library Fundamentals TS) to wrap an allocator into a memory_resource, but we do have a way to wrap a memory_resource into an allocator, I think supporting allocators is the more general approach. Saying "no, you have to use memory resources here" is a plausible design choice, but it would be novel in the std::lib. We haven't, as far as I am aware, decided that memory resources should be preferred in new APIs.

A memory_resource doesn't have a notion of customizable propagation.
An allocator does.