P3818R2: constexpr exception library which is unsurprising in potentially constant initialization

Explainer table

The code in table is intentionally visible, I don't expect users to write constexpr int n = std::uncaught_exceptions() but I do expect users to write code which is using the function deep inside the code, not visibly.

constexpr variables are not a problem

It can be surprising to some users a local constexpr variables are not observing local evaluated context. But it's long established all constexpr variables are starting completely new evaluation without any evaluation context at site of declaration (it can use template variables, other constexpr variables, but not any local variable).

We need to keep constexpr marked functions in order to have the constexpr exception functionality fully working during constant evaluation (storing exceptions temporarily). Failing to do so would make a somehow arbitrary functionality of language again impossible to use and for users to go around, which I strongly prefer to avoid so.

In order to do we must make the potentially-constant initialization evaluation fail when it reaches these two function in question. It's a small surgical and mostly inobservable change which saves us from the silent code change when upgrading to 26. But also it's much better than just removing constexpr.

Immediate (consteval) escalation

Immediate escalation happen only to template-d constexpr function and lamdas, when they has consteval only value of std::meta::info or taking a function pointer of consteval function.

Such functions are then implicitly consteval with all its implications. Like when you call a consteval function from a non-consteval function (these needs to have a codegen, but consteval has no codegen) you will get an error. Unless the function is indendent on its context (all its arguments can be constant evaluated too, or is without any argument), then the function call site is replaced with its result. Look at the following code:

constexpr int CONSTEXPR_number_of_exceptions() {
	return std::uncaught_exceptions();
}

consteval int CONSTEVAL_number_of_exceptions() {
	return std::uncaught_exceptions();
}

template <typename T = void> constexpr int ESCALATED_number_of_exceptions() {
	auto escalate_me = ^^T; // to force escalation
	return std::uncaught_exceptions();
}

struct guard {
	constexpr ~guard() {
		{
			int mutable_v	           = CONSTEXPR_number_of_exceptions();
			const int immutable_v    = CONSTEXPR_number_of_exceptions();
			constexpr int constant_v = CONSTEXPR_number_of_exceptions();
			std::println("constexpr: {}, {}, {}", mutable_v, immutable_v, constant_v);
		}
		{
			int mutable_v	           = CONSTEVAL_number_of_exceptions();
			const int immutable_v    = CONSTEVAL_number_of_exceptions();
			constexpr int constant_v = CONSTEVAL_number_of_exceptions();
			std::println("consteval: {}, {}, {}", mutable_v, immutable_v, constant_v);
		}
		{
			int mutable_v	           = ESCALATED_number_of_exceptions();
			const int immutable_v    = ESCALATED_number_of_exceptions();
			constexpr int constant_v = ESCALATED_number_of_exceptions();
			std::println("escalated: {}, {}, {}", mutable_v, immutable_v, constant_v);
		}
	}
};

int test() {
	const auto g = guard{};
	throw 42;
}

This code prints following result:

constexpr: 1, 0, ?
consteval: ?, ?, ?
escalated: ?, ?, ?

constexpr: 1, 1, 0
consteval: 0, 0, 0
escalated: 0, 0, 0

Notice the questionmarks ? in "before" which marks things which are currently impossible to code. Also notice the 1 in second column for constexpr variant, it takes its runtime / current constant context (not starting a new one).

This is a result of language rule with escalation. And there is no way the constant evaluated escalated function could observe its runtime context, after all, it must not be runtime evaluated, it become consteval.

Much larger but probably breaking solution

We could deprecate and later remove potentially-constant from language. This would make C++ much less surprising, but it will be probably a significant breaking change, altrough not really hard to fix (just make your const variables which suddenly failed to compile constexpr and you are good to go.)

Because of the large impact, this is not proposed.

Duplicate functions under different name specially for constant evaluation

This is what P3820R0 proposes and LEWG rejected it. Removing constexpr from uncaught_exceptions (not from currrent_exception as that one is not touched by the paper) and introduce a same function under similar name. I think that's a bad solution, because these functions are doing same thing, problem is interaction with language rules. Also I really don't think we should introduce same functionality which then would need to be if consteval-ed on every place where we want to use code for both runtime and constant evaluation. It will lead to code like this:

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
		}
	}
}

Previous example shows multiple problems, even if we do introduce new function, we can still can't use it in const int variable initialization, because it would create new constant evaluation and fold into constant. We must avoid const int there completely and we must teach it then.

I fully expect users to write something like following function:

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();
	}
}

And later someone will use this function in const int n = my_uncaught_exceptions initialization and gets burned anyway. Therefore I argue against creating new variable, instead I propose taking proposal of this paper, which will make sure there is no breaking change.

Allow current_exception only in exception handler

This would need to be also transitive and it will introduces non-observable execution state, which can make some constant evaluation to fail irrecoverably. This doesn't solve problem of the std::uncaught_exceptions() at all.

I think it's essential to keep functionality "give me an exception if there is any" available, and not make it "give me an exception or fail compilation", ability to recover must be provided.

This wouldn't solve the original problem:

template <typename T = int> constexpr bool bar() {
	std::meta::info var = ^^T;
	// same applies if `bar` is simple consteval function
	return std::current_exception() != nullptr;
}

constexpr bool foo() { // this needs to have codegen
	try {
		throw 42;
	} catch (...) {
		bool v = bar(); // notice this call to escalated / consteval function
		return v;
	}
}

static_assert(foo() == true); // constant evaluation where `bar()` is evaluated as part of static_assert's evaluation, therefore in constant evaluator

int main() {
	const bool v = foo(); // true
	bool y = foo(); // failure to compile, because `current_exception()`
	                // is called outside exception handler
}

Not change std::uncaught_exception now

If you consider uncaught_exceptions() so broken it needs to fix and you want it to be fixed, we can skip making it constexpr now, but still make current_exception() constexpr.

GCC

I have talked with Jakub and he came to same solution as proposed here.

Feature test macros

17.3.2 Header <version> synopsis [version.syn]

#define __cpp_lib_constexpr_exceptions 20250226??LL // also in <exception>, <stdexcept>, <expected>, <optional>, <variant>, and <format>