noexcept
serves two purposes: it describes an interface, and it improves performance. The first is important even when the function is trivial, in that it documents that (in all compatible versions) it will stay non-throwing even if the implementation becomes more complex (and perhaps stops being inline). That property is important for clients that want to write exception-safe code (and changing it can silently break them).
The second has two components: while direct code generation may be unaffected when the body is simple and available, the library behavior associated with a type depends only on its declaration (which is a good thing, given the interface idea). Libraries tend to check the potential for throwing from only a few functions (especially the special member functions), so that’s unlikely to matter in this case, but do note that the space of “special” functions grows over time (e.g., swap
, operator==
).
The conclusion is that you should write noexcept
when it’s important—either to your human readers or to your analyzing libraries.