Is there an automatic noexcept specifier?

Question

I've heard that noexcept keyword is more like 'it should never throw an exception' rather than 'it doesn't'.

I don't think it's good to use noexcept keyword if I'm not sure it throws an exception or not, but noexcept keyword is sometimes related to the performance like in a move constructor.

So I tried to use noexcept qualifiers, but it gets harder if it has multiple statements in the definition and it becomes a kind of copy-and-paste thing.

template <class T>
void f(T&& t)
    noexcept(noexcept(statement_1) &&
             noexcept(statement_2) &&
             noexcept(statement_3) &&
             noexcept(statement_4) &&
             noexcept(statement_5))
{
    statement_1;
    statement_2;
    statement_3;
    statement_4;
    statement_5;
}

I think the compiler can figure out whether the definition of a function consists of non-throwing statements, so it will be easier to utilize noexcept if there's an expression like noexcept(auto), but it seems that there is no such thing in the standard.

Is there any way to simplify the noexcept expression?

Answer 1

Currently there is none. There is, however, a proposal on that topic, which proposes noexcept(auto) syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4473 The status of this proposal is "needs further work", according to Botond Ballo's "Trip Report: C++ Standards Meeting in Lenexa, May 2015" https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/

Further Work. The proposal’s direction is promising, but it is either not fleshed out well enough, or there are specific concerns with one or more design points. The author is encouraged to come back with a modified proposal that is more fleshed out and/or addresses the stated concerns.

...

noexcept(auto), which basically means “deduce the noexcept-ness of this function from the noexcept-ness of the functions it calls. Like return type deduction, this requires the body of the function being available in each translation unit that uses the function. It was brought up that, together with the proposal for making exception specifications part of the type system, this would mean that modifying the function’s body could change the function’s type (again similarly to return type deduction), but people weren’t overly concerned about that.