Re: Relocation (= move+destroy)

[Jonathan Wakely <jwakely at redhat dot com>]

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