Does it make sense to declare inline functions noexcept?

Question

From what I can tell, the SO community is divided on whether declaring a function noexcept enables meaningful compiler optimizations that would not otherwise be possible. (I'm talking specifically about compiler optimizations, not library implementation optimizations based on move_if_noexcept.) For purposes of this question, let's assume that noexcept does make meaningful code-generation optimizations possible. With that assumption, does it make sense to declare inline functions noexcept? Assuming such functions are actually inlined, this would seem to require that compilers generate the equivalent of a try block around the code resulting from the inline function at the call site, because if an exception arises in that region, terminate must be called. Without noexcept, that try block would seem to be unnecessary.

My original interest was in whether it made sense to declare Lambda functions noexcept, given that they are implicitly inline, but then I realized that the same issues arise for any inline function, not just Lambdas.

Answer 1

let's assume that noexcept does make meaningful code-generation optimizations possible

OK

Assuming such functions are actually inlined, this would seem to require that compilers generate the equivalent of a try block around the code resulting from the inline function at the call site, because if an exception arises in that region

Not necessarily, because it might be that the compiler can look at the function body and see that it cannot possibly throw anything. Therefore the nominal exception-handling can be elided.

If the function is "fully" inlined (that is, if the inlined code contains no function calls) then I would expect that the compiler can fairly commonly make this determination -- but not for example in a case where there's a call to vector::push_back() and the writer of the function knows that sufficient space has been reserved but the compiler doesn't.

Be aware also that in a good implementation a try block might not actually require any code at all to be executed in the case where nothing is thrown.

With that assumption, does it make sense to declare inline functions noexcept?

Yes, in order to get whatever the assumed optimizations are of noexcept.

Answer 2

It is worth noting that there was an interesting discussion in circles of power about nothrow-related issues. I highly recommend reading these:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3227.html

http://www.stroustrup.com/N3202-noexcept.pdf

Apparently, quite influential people are interested in adding some sort of automatic nothrow deduction to C++.

After some pondering I've changed my position to almost opposite, see below

Consider this:

• when you call a function that has noexcept on declaration -- you benefit from this (no need to deal with unwindability, etc)

• when compiler compiles a function that has noexcept on definion -- (unless compiler can prove that function is indeed nothrow) performance suffers (now compiler needs to ensure that no exception can escape this function). You are asking it to enforce no-exceptions promise

I.e. noexcept both hurts you and benefits you. Which is not the case if function is inlined! When it is inlined -- there is no benefit from noexcept on declaration whatsoever (declaration and definition become one thing)... That is unless you are actually want compiler to enforce this for safety sake. And by safety I mean you'd rather terminate than produce wrong result.

It should be obvious now -- there is no point declaring inlined functions noexcept (keep in mind that not every inline function is gonna get inlined).

Lets have a look at different categories of functions which don't throw (you just know they don't):

1. non-inlined, compiler can prove it doesn't throw -- noexcept won't hurt function body (compiler will simply ignore specification) and call sites will benefit from this promise

2. non-inlined, compiler can't prove it doesn't throw -- noexcept will hurt function body, but benefit call sites (hard to tell what is more beneficial)

3. inlined, compiler can prove it doesn't throw -- noexcept serves no purpose

4. inlined, compiler can't prove it doesn't throw -- noexcept will hurt call site

As you see, nothrow is simply badly designed language feature. It only works if you want to enforce no-exception promise. There is no way to use it correctly -- it can give you "safety", but not performance.

noexcept keyword ended up being used both as promise (on declaration) and enforcement(on definition) -- not a perfect approach, I think (lol, second stab at exception specs and we still didn't get it right).

So, what to do?

1. declare your behavior (alas, language has nothing to help you here)! E.g.:

   void push_back(int k);   // throws only if there is no unused memory
   

2. don't put noexcept on inline functions (unless it is unlikely to be inlined, e.g. very large)

3. for non-inline functions (or function that is unlikely to be inlined) -- make a call. The larger function gets the smaller noexcept's negative effect becomes (comparatively) -- at some point it probably makes sense specifying it for callers' benefit

4. use noexcept on move constructor and move assignment operator (and destructor?). It could affects them negatively, but if you don't -- certain library functions (std::swap, some container operations) won't take the most efficient path (or won't provide the best exception guarantee). Basically any place that uses noexcept operator on your function (as of now) will force you to use noexcept specifier.

5. use noexcept if you don't trust calls your function makes and rather die than have it behave unexpectedly

6. pure virtual functions -- more often than not you don't trust people implementing these interfaces. Often it makes sense buying insurance (by specifying noexcept)

Well, how else noexcept could be designed?

1. I'd use two different keywords -- one for declaring a promise and another for enforcing it. E.g. noexcept and force_noexcept. In fact, enforcement isn't really required -- it can be done with try/catch + terminate() (yes, it will unwind the stack, but who cares if it is followed by std::terminate()?)

2. I'd force compiler to analyze all calls in given function to determine if it can throw. If it does and a noexcept promise was made -- compiler error will be emitted

3. For code that can throw, but you know it doesn't there should be a way to assure compiler that it is ok. Smth like this:

   vector<int> v;
   v.reserve(1);
   ...
   nothrow {       // memory pre-allocated, this won't throw
       v.push_back(10);
   }
   

   if promise is broken (i.e. someone changed vector code and now it provides other guarantees) -- undefined behavior.

Disclaimer: this approach could be too impractical, who knows...