P3818R1: constexpr exception fix for potentially constant initialization

Revision history

• R0 → R1: added section discussing changes proposed in P3820, added comparison table to explaing subtle differences between various types of variables and their initialization, added comparison table between P3818 and P3820 proposals.

The problem to fix

C++ has many corner cases and this one is one of them. A constant variable (marked const) which is integral or enumeration type is upgraded to constexpr variable silently if its initialization succeed in constant evaluation. This is usually unobservable, because you can't reference anything around to succeed.

auto function_returning_empty_array() {
	const int n = calculate_size_needed(); // this needs to be a constant evaluated => constexpr
	return std::array<int, n>{}; // so we can change type based on `n`
}

This is a problem for constexpr exceptions, which needs constexpr marked functions in order for them work inside constant evaluation. But once marked constexpr a function can be evaluated there, which is a problem for two functions added byP3068 (std::uncaught_exceptions and std::current_exceptions) as these don't have dependency on any local variable which would disallow constant evaluation. These have only an implicit dependency on local context which allows them to be succesfully evaluated in const variable potentially-constant initialization.

This potentially-constant initialization starts as any constant evaluation a new context, in which there are no unrolling or current exception, so these function will return constant which is something else user wants.

try {
	// some exception throwing code
} catch (const std::exception & exc) {
	const bool has_exception = (std::current_exception() != nullptr); // no current exception in a catch handler?!
	static_assert(has_exception == false); // success here
}

Variable has_exception is silently upgraded to a constexpr variable. And records different context than a user expects. Another even more scary example:

struct transaction {
	// ...
	void cancel() { /* revert changes */ }
	
	~transaction() {
		const bool unrolling = std::uncaught_exceptions() > 0;
		
		if (unrolling) { // this will never be evaluated
			log("exception was thrown in a transaction => cancel()");
			cancel();
		}
	}
}

Note: I know this example should contain call in std::uncaught_exceptions() so we can actually know if an there is a new exception, but in order to simplify it I did what I did.

In previous example std::uncaught_exceptions() > 0 is constant evaluated in a vacuum, even sooner than the destructor transaction::~transaction() is finished parsing. And because in that specific constant evaluation, there is no uncaught exception, it will return 0, obviously. The whole unrolling becomes constexpr, and your transactions will never cancels. This is really scary.

Proposed solution

Keep constexpr on both methods (std::uncaught_exceptions() and std::current_exceptions) and disallow them to be constant evaluated explicitly only in potential-constant initialization [expr.const].

This is a minimal and implemented solution which doesn't limit functionality, but removes the break.

Possible alternatives

constexpr foo::~foo() {
	if consteval {
		/* const */ int num_of_exceptions = std::consteval_uncaught_exceptions();
		if (num_of_exceptions != num_of_exceptions_before) {
			// do something now we know there is an exception unrolling
		}
 	} else {
		const int num_of_exceptions = std::uncaught_exceptions();
		if (num_of_exceptions != num_of_exceptions_before) {
			// do something now we know there is an exception unrolling
		}
	}
}

constexpr int my_uncaught_exceptions() {
	if consteval {
		// for some reason committee gave us this function, 
		// but I need this to initialize variable, so I can't use
		// if consteval there
		return std::consteval_uncaught_exceptions();
	} else {
		return std::uncaught_exceptions();
	}
}

Positive / negative comparison

Following table compare positives and negatives of this paper and P3820.

Implementation experience

The proposed solution was implemented in my clang prototype of constexpr exception for std::uncaught_exceptions(), and you can experiment with it at the compiler explorer.

The change itself was add to clang know in its evaluation state the evaluation is potentially-constant. And then the builtins implementing the exception handling function to detect it and fail to evaluate in that case.

There was a minor problem around initialization of a local constexpr variables, which for some reason are not cached, and are reinitialized as part of evaluation with same evaluation state. This lead to a funny error when following code didn't compile (reported to me by Ville):

const int n = []{
	constexpr int x = std::uncaught_exceptions(); // initialized twice, once during parsing 
																								// and second time during evaluation of the lambda
	return x;
}();

Clang when it sees initialization of a local constexpr variable it evaluates its initialization again, even when the value could be cached. This second evaluation in my first version was in potentially-constant state, and then the exception support function didn't work silently. Fix was changing the state of evaluation for initializers of local constexpr variables, and restoring previous one when the initialization is finished.

Wording

Change is add a new Constant when to std::uncaught_exceptions() and std::current_exception().