Hi,

I'm wondering whether it would make sense to allow pmr::pool_options to
list the exact block sizes this pool allocator should cater for.

I mean, in a pmr::list<pmr::string>, I might want to allocate the nodes
in a pool together, but not randomly intersperse them with string data.
Sure, in this case, I might get away with pmr::list<std::string>, but
more complex scenarios are readily created. pmr::polymorphic_allocator
implements the scoped model, but doesn't seem to have the flexibility of
the real thing (scoped_allocator_adaptor).

Another use-case is: if I know I only have block sizes of 4 and 8, say,
then having less pools may have less runtime overhead.

I know I can readily implement my own memory_resource to do just that,
and the question is whether pool_resource is the correct class to
implement this in, or whether a new class is better; I guess what I'm
trying to ask is: am I missing something?

Thanks,
Marc