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.
