Subject: Re: [isocpp-lib-ext] D1030R4 draft 2: std::filesystem::path_view
From: Ville Voutilainen (ville.voutilainen_at_[hidden])
Date: 2020-10-21 11:23:42
On Wed, 21 Oct 2020 at 19:13, Jonathan Wakely via Lib-Ext
>> 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.
SG16 list run by firstname.lastname@example.org