[PATCH] Add missing noexpect causes in tuple for move functions

[Nicholas Krause]

This adds the remainging noexcept causes required for this cause
to meet the spec as dicussed last year and documented here:
http://cplusplus.github.io/LWG/lwg-active.html#2899.

Signed-off-by: Nicholas Krause <***@gmail.com>
---
libstdc++-v3/include/std/tuple | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 56b97c25eed..d17512a1b7e 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -214,6 +214,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if<sizeof...(_Tail) == sizeof...(_UTail)>::type>
explicit
constexpr _Tuple_impl(_UHead&& __head, _UTail&&... __tail)
+ noexcept(__and_<is_nothrow_move_constructible<_Head>,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::forward<_UTail>(__tail)...),
_Base(std::forward<_UHead>(__head)) { }

@@ -237,6 +239,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

template<typename _UHead, typename... _UTails>
constexpr _Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&& __in)
+ noexcept(__and_<is_nothrow_move_constructible<_Head>,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::move
(_Tuple_impl<_Idx, _UHead, _UTails...>::_M_tail(__in))),
_Base(std::forward<_UHead>

[nick]

Post by Nicholas Krause
This adds the remainging noexcept causes required for this cause
http://cplusplus.github.io/LWG/lwg-active.html#2899.

This isn't "the spec", it's a proposed (but incorrect) resolution to a
defect in the standard. What it proposes may not fix the defect, but I
think it's an improvement to the std::tuple API anyway, and so I want
libstdc++ to implement it. "The spec" is the C++ standard, but it
explicitly allows implementations to add stronger
exception-specifications where a function is known not to throw.
Thanks for the patch. Something this small could be accepted without a
copyright assignment, but as it seems like you're interested in
contributing more (which is great!) you should be aware of the legal
prerequisites for larger contributions (which also applies to several
small contributions, even if each one is trivial). See
https://gcc.gnu.org/contribute.html for details, and let me know if
you have any questions about that.

Jonathan,

My only question remains is for copyright is it per patch or just one time.

My other question is related to the noexcept parts and that either I or
you should move and CC the other involed list i.e. the llibstdc++ list.

Cheers,

Nick

[nick]

Post by nick

Post by Nicholas Krause
This adds the remainging noexcept causes required for this cause
http://cplusplus.github.io/LWG/lwg-active.html#2899.

This isn't "the spec", it's a proposed (but incorrect) resolution to a
defect in the standard. What it proposes may not fix the defect, but I
think it's an improvement to the std::tuple API anyway, and so I want
libstdc++ to implement it. "The spec" is the C++ standard, but it
explicitly allows implementations to add stronger
exception-specifications where a function is known not to throw.
Thanks for the patch. Something this small could be accepted without a
copyright assignment, but as it seems like you're interested in
contributing more (which is great!) you should be aware of the legal
prerequisites for larger contributions (which also applies to several
small contributions, even if each one is trivial). See
https://gcc.gnu.org/contribute.html for details, and let me know if
you have any questions about that.

Jonathan,
My only question remains is for copyright is it per patch or just one time.
My other question is related to the noexcept parts and that either I or
you should move and CC the other involed list i.e. the llibstdc++ list.

You can submit one copyright assignment per patch ... if you're a masochist.
The recommended approach is a single "Futures" copyright assignment
for all current and future patches.
Thanks, David

It mentions on the page to just ask about copyright forms, so I am asking here
for them before I just send them to the assign email address given.

Nick