The _GET_PROXY_ALLOCATOR macro looks a bit scary (at least the macro name is a bit SHOUTING) and hard to understand.

It seems to me that the first macro parameter is unnecessary - as the source type for _Rebind_alloc_t can be deduced from _Al (e.g. it can be _Remove_cvref_t<decltype(_Al)>). Should we remove the first macro parameter and its uses?

Also, since #5335, the _GET_PROXY_ALLOCATOR macro always expands to a prvalue expression, so when we receive it with a variable, it seems clearer to use plain auto instead of currently used auto&&.

On the other hand, would it be better to encapsulate the functionality into a function template?

• Pros:
  • It can have a less SHOUTING name, e.g. _Get_proxy_allocator or _Rebind_for_proxy.
  • Users and maintainers won't think that it needs some unusual mechanisms.
• Cons:
  • More operations would be performed in debug builds.
  • More steps would be required for constant evaluation, which makes constant evaluation less functional for a particular step limit.

Or, given the dynamically allocated proxy objects will likely to be eliminated in vNext, would improvements for this be unworthy?