pmr::polymorphic_allocator, scoped_allocator_adaptor, and uses_allocator

[AnabelSMRuggiero]

Mark had mentioned earlier that supporting the memory resources in std::pmr was a hurdle that mdarray needed to get over;std::pmr::polymorphic_allocator follows the same scoped allocator model that is supported by std::scoped_allocator_adaptor and std::uses_allocator. Unless I'm missing something, the main things needed to fully support the scoped allocator model (when container_type::allocator_type exists) are:

• Add a constructor to basic_mdarray that allows it to have an allocator passed in that passes the allocator to container_policy::create()
• ~Support T(std::allocator_arg, alloc, size) as a possible container constructor and~
• Partial specialize std::uses_allocator to be based on basic_mdarray::container_type

I should be able to piece together most of a PR implementing uses allocator construction over the weekend.

Edit: got a bit ahead of myself and forgot that the relevant policy was specifically for vectors; supporting uses allocator construction for other containers would be the responsibility of the relevant policy.

[mhoemmen]

@AnabelSMRuggiero Thanks for posting! : - )

. . . supporting uses allocator construction for other containers would be the responsibility of the relevant policy.

The change would need to account for containers that don't use an allocator, in particular std::array.

[AnabelSMRuggiero]

Yeup, accounting for non-allocator aware containers is the biggest confounding issue, and why I ended up resorting to raw SFINAE. My thinking is that I need template argument deduction to fail so I can get the allocator type in a dependent context. Naming it in a non-dependent context produces a compile time error. The type trait for getting the allocator type produces a hard error at template deduction, not a SFINAE error, and constraints are checked during overload resolution after template deduction. The only thing I could think of (aside from partial specialization) was to guard getting the allocator type through a defaulted template parameter behind a SFINAE error. Of course I absolutely could have missed something, but this was the only way I could get it to compile 🙃

[crtrott]

Note: we are changing the design of mdarray to get rid of container policy. Its not clear that that thing really provides much value. Basically we just gonna template on the container itself. I will upload a draft new version later today. Did not have time to look at implementation yet.