Relocation (= move+destroy)

[Jonathan Wakely]

On 13/10/18 19:00 +0200, Marc Glisse wrote:
>On Sat, 13 Oct 2018, Jonathan Wakely wrote:
>
>>On 13/10/18 11:07 +0200, Marc Glisse wrote:
>>>--- libstdc++-v3/include/bits/alloc_traits.h	(revision 265131)
>>>+++ libstdc++-v3/include/bits/alloc_traits.h	(working copy)
>>>@@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>	  using type = decltype(__test<_Alloc>(0));
>>>	};
>>>
>>>      template<typename _Tp, typename... _Args>
>>>	using __has_construct
>>>	  = typename __construct_helper<_Tp, _Args...>::type;
>>>
>>>      template<typename _Tp, typename... _Args>
>>>	static _Require<__has_construct<_Tp, _Args...>>
>>>	_S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
>>>+	noexcept(noexcept(__a.construct(__p, 
>>>std::forward<_Args>(__args)...)))
>>
>>You could use std::declval<_Args>()... instead of forwarding __args...
>>which would be slightly shorter (and might keep some of the others on
>>a single line). No need to change it unless you want to, either is OK.
>
>In order to reduce the risk of bugs, my preference is
>
>1) noexcept(auto): I am amazed that no compiler has implemented it 
>yet, even as a private extension spelled __noexcept_auto or whatever, 
>since it reduces significantly the burden on standard library 
>developers. As a recent example, PR 87538 would never have had a 
>chance to exist.
>
>2) an exact copy-paste of the body of the function.

That's a good enough reason for me. Unless one of us implements
noexcept(auto) in GCC and Clang in the next few days, let's go with
what you have in the patch :-)


>3) something else only if needed, for instance because 2) misses the 
>conversion to the result type.
>
>Of course, since there is more chance *you* will have to maintain that 
>mess, whatever style you find easier to maintain is more important.
>
>-- 
>Marc Glisse