[Bug c++/94811] New: Please make make_tuple noexcept when possible

[Bug c++/94811] New: Please make make_tuple noexcept when possible

[rafael at espindo dot la]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811

            Bug ID: 94811
           Summary: Please make make_tuple noexcept when possible
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rafael at espindo dot la
  Target Milestone: ---

The standard in res.on.exception.handling says:

An implementation may strengthen the exception specification for a non-virtual
function by adding a non-throwing exception specification.

So it should be possible to make the std::tuple constructor and std::make_tuple
noexcept when the arguments have noexcept copy or move constructors.

[Bug libstdc++/94811] Please make make_tuple noexcept when possible

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++
           Severity|normal                      |enhancement

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Sure, it is possible, but isn't std::make_tuple mostly legacy at this point,
with CTAD you can just use std::tuple, which is noexcept already.

Each extra noexcept is one more chance to get things wrong, at least as long as
wg21 refuses noexcept(auto), although this particular case doesn't seem
particularly hard.

[Bug libstdc++/94811] Please make make_tuple noexcept when possible

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #1)
> Each extra noexcept is one more chance to get things wrong

And slows down compilation due to instantiating the trait class templates
(which G++ was doing even when not being checked by a noexcept-expression, but
I think that might have been fixed recently).

[Bug libstdc++/94811] Please make make_tuple noexcept when possible

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Rafael Avila de Espindola from comment #0)
> So it should be possible to make the std::tuple constructor and

Isn't that already done?

> std::make_tuple noexcept when the arguments have noexcept copy or move
> constructors.

make_tuple should depend on the tuple being constructed, not on the individual
elements, because make_tuple is constructing a tuple, not constructing the
elements.

But I think this is slightly complicated by guaranteed copy elision in C++17.
For C++14 the make_tuple function depends on whether constructing the tuple can
throw *and* whether copying the return value can throw, for C++17 it only
depends on the former.

[Bug libstdc++/94811] Please make make_tuple noexcept when possible

[rafael at espindo dot la]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811

--- Comment #4 from Rafael Avila de Espindola <rafael at espindo dot la> ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Rafael Avila de Espindola from comment #0)
> > So it should be possible to make the std::tuple constructor and
> 
> Isn't that already done?

It is :-)

I had tested this bit with gcc 9, but with 10 the following assert passes:

static_assert(std::is_nothrow_constructible_v<std::tuple<int>, int>);

Given CTAD I am happy to call this bug fixed if you want.

[Bug libstdc++/94811] Please make make_tuple noexcept when possible

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
OK thanks