LWG-4267 Uses-allocator construction is meaningless for tuple of references

[StephanTLavavej]

LWG-4267 Uses-allocator construction is meaningless for tuple of references

It's unclear to me whether any implementation work is needed here.

[frederick-vs-ja]

STL/stl/inc/tuple

Lines 132 to 152 in 488e795

	constexpr _Tuple_val() : _Val() {}
	template <class _Other>
	constexpr _Tuple_val(_Other&& _Arg) : _Val(_STD forward<_Other>(_Arg)) {}
	template <class _Alloc, class... _Other, enable_if_t<!uses_allocator_v<_Dty, _Alloc>, int> = 0>
	constexpr _Tuple_val(const _Alloc&, allocator_arg_t, _Other&&... _Arg) : _Val(_STD forward<_Other>(_Arg)...) {}
	template <class _Alloc, class... _Other,
	enable_if_t<conjunction_v<_STD uses_allocator<_Dty, _Alloc>,
	_STD is_constructible<_Ty, _STD allocator_arg_t, const _Alloc&, _Other...>>,
	int> = 0>
	constexpr _Tuple_val(const _Alloc& _Al, allocator_arg_t, _Other&&... _Arg)
	: _Val(allocator_arg_t{}, _Al, _STD forward<_Other>(_Arg)...) {}
	template <class _Alloc, class... _Other,
	enable_if_t<conjunction_v<_STD uses_allocator<_Dty, _Alloc>,
	_STD negation<_STD is_constructible<_Ty, _STD allocator_arg_t, const _Alloc&, _Other...>>>,
	int> = 0>
	constexpr _Tuple_val(const _Alloc& _Al, allocator_arg_t, _Other&&... _Arg)
	: _Val(_STD forward<_Other>(_Arg)..., _Al) {}

In _Tuple_val, we need to ensure that when _Ty is a reference type (so is _Dty), the 4th and 5th overloads won't be selected. Looks like that we've already achieved this as long as it can be assumed that uses_allocator_v<R, A> is always false if R is a reference type.

Such assumption is safe to me.

• Per [defns.prog.def.type], a reference type is never a program-defined type.
• Per [allocator.uses.trait]/1, users are only allowed to specialize uses_allocator for program-defined types.

So IIUC, MSVC STL's implementation details already work. Perhaps it would be desired to add test coverage for this. Do we also want to defend against invalid user-defined specializations?

[StephanTLavavej]

Sounds great, thanks.

Yes, I think a bit of test coverage would be a good idea.

No, I don't think we need to go to the effort of defending against wacky user-defined specializations.