Date: 2016-08-08 Project: Programming Language C++ Reply-To: Kamil Rojewski
A proposal for noexcept(auto) exception specification I.
Introduction
An automatic exception specification, noexcept(auto), is proposed as a means to improve exception safety, fix problems of testing noexcept code and lessen burden on programmers when writing sometimes convoluted noexcept expressions.
II. Motivation noexcept exception specification allows programmers to mark a function conditionally nonthrowing by allowing them to provide a boolean expression, enabling or disabling all exceptions. Unfortunately, it has some inherent problems: •
Complex condition expressions can be error prone and result in invalid exception specification. Also, the readability (and thus maintainability) of such code suffers.
•
noexcept functions are hard to test. This was discussed in N3248 when noexcept specifiers for the Standard Library were considered. Ultimately, conditional noexcepts have been (mostly) dropped due to their problems.
•
Expressions for noexcept must be constantly monitored along with code changes.
noexcept(auto) aims at solving those problems by marking functions as conditionally noexcept, based on their static analysis by the compiler.
III. Impact On the Standard Compilers today are already required to do an analysis on possible no-throwing guarantee. For example, an implicitly declared special member function is required to have an exception specification, which is based on its implicit definition (this is specified in detail in part 15.4.14 of the Standard). This proposal allows the programmer to directly involve this mechanism to deduce if a function can be marked noexcept, by declaring it as noexcept(auto). Thus, an extensions to part 15.4 of the Standard is required.
IV. Design Decisions This approach was specifically chosen to leverage existing mechanisms with minimal impact on the Standard. It also solves the long-unresolved problem described in N3248. Backwards compatibility is retained, and no changes to existing code are necessary.
V. Technical Specifications Additions to part 15.4 [except.spec] of the Standard (marked in green):
1. A function declaration lists exceptions that its function might directly or indirectly throw by using an exception-specification as a suffix of its declarator. exception-specification: dynamic-exception-specification noexcept-specification dynamic-exception-specification: throw ( type-id-listopt ) type-id-list: type-id ...opt type-id-list , type-id ...opt noexcept-specification: noexcept ( constant-expression ) noexcept(auto) noexcept
In a noexcept-specification, the constant-expression, if supplied, shall be a constant expression (5.19) that is contextually converted to bool (Clause 4). A noexcept-specification noexcept is equivalent to noexcept(true). A ( token that follows noexcept is part of the noexceptspecification and does not commence an initializer (8.5).
12. A function with no exception-specification, with an exception-specification of the form noexcept(constant-expression ) where the constant-expression yields false, or with an exceptionspecification of the form noexcept(auto) where any of the functions it directly invokes allows any exception, allows all exceptions. An exception-specification is non-throwing if it is of the form throw(), noexcept, noexcept(constant-expression ) where the constant-expression yields true, or noexcept(auto) where every function directly invoked allow no exceptions. A function with a nonthrowing exception-specification does not allow any exceptions. An exception-specification is not considered part of a function’s type.
VI. References Alisdair Meredith, John Lakos, 2011, noexcept Prevents Library Validation, N3248
