[Bug libstdc++/102567] New: Missing noexcept specialization of std::function

[Bug libstdc++/102567] New: Missing noexcept specialization of std::function

[fw at gcc dot gnu.org]

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

            Bug ID: 102567
           Summary: Missing noexcept specialization of std::function
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

When C++17 made noexcept part of the type system, std::function was not updated
accordingly. As a result, this program fails to compile:

#include <functional>
std::function<void() noexcept> f;

t.cc:2:32: error: aggregate ‘std::function<void() noexcept> f’ has incomplete
type and cannot be defined
    2 | std::function<void() noexcept> f;
      |                                ^

In earlier language versions, code like this used to compile because noexcept
was not part of the type system.

Seen with: gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)

[Bug libstdc++/102567] Missing noexcept specialization of std::function

[redi at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is not a libstdc++ bug, we implement what the standard says.

Maybe it used to compile, but it was meaningless. You could say it was a
function of void() noexcept, but you could still store a target function that
throwed, and its operator() could still throw.

Both std::move_only_function (P0288) and std::function_ref (P0792) support
using a function type that is optionally const-qualified and optionally
noexcept, and it actually means something (it affects what you can store in
there, and whether they can modify a stateful target object, and whether their
operator() is noexcept or not). std::function is not going to get updated
though.

[Bug libstdc++/102567] Missing noexcept specialization of std::function

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Florian Weimer from comment #0)
> In earlier language versions, code like this used to compile because
> noexcept was not part of the type system.

This also used to compile:

void f() noexcept(false);
void (*p)() noexcept = &f;

But it was meaningless, p() could still throw. In C++17 it doesn't work.

[Bug libstdc++/102567] Missing noexcept specialization of std::function

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> This is not a libstdc++ bug, we implement what the standard says.
> 
> Maybe it used to compile, but it was meaningless. You could say it was a
> function of void() noexcept, but you could still store a target function
> that throwed, and its operator() could still throw.

Sure, but in my code, I did not do this. The call operator was invoked in a
noexcept context, and the type was expected to match (but of course the
compiler did not check this).

> Both std::move_only_function (P0288) and std::function_ref (P0792) support
> using a function type that is optionally const-qualified and optionally
> noexcept, and it actually means something (it affects what you can store in
> there, and whether they can modify a stateful target object, and whether
> their operator() is noexcept or not). std::function is not going to get
> updated though.

Neither paper seems to cover a polymorphic function type that takes ownership,
though, so I don't quite see how these replace std::function.

Or is std::function semi-deprecated because it poorly matches
capture-by-reference in lambdas?

[Bug libstdc++/102567] Missing noexcept specialization of std::function

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Florian Weimer from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > This is not a libstdc++ bug, we implement what the standard says.
> > 
> > Maybe it used to compile, but it was meaningless. You could say it was a
> > function of void() noexcept, but you could still store a target function
> > that throwed, and its operator() could still throw.
> 
> Sure, but in my code, I did not do this. The call operator was invoked in a
> noexcept context, and the type was expected to match (but of course the
> compiler did not check this).

Then you need to stop doing it, the C++17 changes make it no longer possible to
use that extra annotation in the type to signify something that wasn't checked,
or even necessarily true.

> Neither paper seems to cover a polymorphic function type that takes
> ownership, though, so I don't quite see how these replace std::function.

They're not supposed to replace it, they supplement it for additional scenarios
(non-owning, or owning a movable but non-copyable target).

My point is just that the newer facilities being added do allow you to use
noexcept the way you want to, but std::function doesn't. And I doubt anybody is
going to propose extending it that way.

Either way, it's not a libstdc++ bug.

[Bug libstdc++/102567] Missing noexcept specialization of std::function

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Florian Weimer from comment #3)
> Neither paper seems to cover a polymorphic function type that takes
> ownership, though, so I don't quite see how these replace std::function.

To be clear, std::move_only_function is exactly a polymorphic function type
that takes ownership. Without the constraint that the target type it takes
ownership of needs to be copy-constructible.

[Bug libstdc++/102567] Missing noexcept specialization of std::function

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
std::move_only_function is on trunk now.