`<xmemory>`: Should we modernize `_GET_PROXY_ALLOCATOR` (and its usages)?

[frederick-vs-ja]

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

STL/stl/inc/xmemory

Lines 1506 to 1515 in b5df16a

	#if _ITERATOR_DEBUG_LEVEL == 0
	#define _GET_PROXY_ALLOCATOR(_Alty, _Al) \
	_Fake_allocator {}
	template <class _Alloc>
	using _Container_proxy_ptr = _Fake_proxy_ptr_impl;
	#else // ^^^ _ITERATOR_DEBUG_LEVEL == 0 / _ITERATOR_DEBUG_LEVEL > 0 vvv
	#define _GET_PROXY_ALLOCATOR(_Alty, _Al) static_cast<_Rebind_alloc_t<_Alty, _Container_proxy>>(_Al)
	template <class _Alloc>
	using _Container_proxy_ptr = _Container_proxy_ptr12<_Rebind_alloc_t<_Alloc, _Container_proxy>>;
	#endif // ^^^ _ITERATOR_DEBUG_LEVEL > 0 ^^^

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?

[StephanTLavavej]

I am in favor of making this into a function template, so we can deduce the type of the provided allocator, and reduce our usage of internal macros. I am not particularly worried about the cost for debug builds (since this is on an allocation codepath which is quite expensive; a non-inlined function call is a drop in the bucket), and same for constexpr evaluation (anything hammering constexpr dynamic allocations is already doing something pretty expensive, an extra function call isn't too bad).