CWG2776 Substitution failure and implementation limits

[jensmaurer]

Reaching implementation limits (even at compile-time) essentially causes IFNDR in the status quo.
A more defensive specification might be more helpful to users.

See details in CWG2776.

[davidstone]

Example in which evaluation limits determine overload resolution:

constexpr int f(int max) {
	for (int n = 0; n != max; ++n) {
	}
	return 0;
}

int const x = f(1048572);
int const y = f(1048573);

template<int = x>
constexpr bool f() {
	return true;
}

template<int = y> requires true
constexpr bool f() {
	return false;
}

static_assert(f());

https://godbolt.org/z/vzf847MYc

Same example without needed global constant int:

constexpr int f(int max) {
	for (int n = 0; n != max; ++n) {
	}
	return 0;
}

template<int = f(1048572)>
constexpr bool g() {
	return true;
}

template<int = f(1048573)> requires true
constexpr bool g() {
	return false;
}

static_assert(g());

See it live: https://godbolt.org/z/441PzG517

[erichkeane]

EWG discussed CWG2776 during the Tuesday Morning session in Kona. The following polls were taken.

CWG2776 "Substitution failure and implementation limits" we would like to resolve this issue by making it ill-formed to hit an implementation limit (such as constexpr evaluation) and later using this 'failed constexpr" value (or a derived value) in a context where constexpr is required. A paper is required.

SF	F	N	A	SA
0	8	7	2	1

Result: Not Consensus

CWG2776 "Substitution failure and implementation limits" we would like to see a paper which makes this either IF-NDR, or well-formed.

SF	F	N	A	SA
1	6	2	2	0

Result: Consensus

[hanickadot]

EWG St. Louis: @cor3ntin volunteered to write a paper