> The general structure of the IFNDR list in [temp.res.general] p6
> is that IFNDR triggers only if no actual use (instantiation etc.)
> of the construct appears in the program.

> If such a use would appear in the program, a compiler diagnostic
> is expected.

But here is where I am focusing on because,
based on [temp.constr.atomic]-p3, in case of errors
in immediate context, the constraint-expression just
evaluates to false without making the program ill-formed.

The same holds for requires-expression (§ [expr.prim.req.general]-p5),

except that an expression impossible-to-satisfy is considered
an IFNDR in [expr.prim.req.general]-p5, regardless of any
actual check on the expression.
At the opposite, the text in [temp.res.general] p(6.4) shows
a different intent for the constraint-expressions.

> However, designating a program as IFNDR means that
> the compiler is relieved from the duty of producing any diagnostic
> at all; see [intro.compliance.general] p2.

ok

> Thus, the carve-out is intended to keep requiring a diagnostic
> if a use of the construct appears in the program, and otherwise
> still call the program ill-formed, but not require a diagnostic
> from the compiler.

As remarked above, an error in the immediate context does
not lead to ill-form in case of constraint-expressions and
requires-expressions.

Consider the following example:

template<typename T>
requires (T < -1)
int func(){return 0;};

template<typename T>
requires (T{} > -1)
int func(){return 0;};

int a = func<int>();

int main(){}

We have two overloads for func(), the first of them
using an always-non-satisfied constraint due to
invalid expression (T < -1).
Does the (implicit) instantiation of func<int>
determine a satifaction check for the first overload ?

If yes then, based on [temp.res.general] p(6.4),
compilers should not diagnose, but on
godbolt (https://godbolt.org/z/cqb511Wa9) I do
see that gcc and clang diagnose it, whereas
MVSC does not. This seems a case of IFNDR.

So, I still wonder about the apparently
relaxed intended behaviour
for constraint-expressions, compared to
requires-expressions. And I do see that
the comparison between some of major
compilers seem showing an IFNDR case
regardless of satisfation checks in place.


Finally, let me notify that my last original point
about templated vs non-template entity
does not make sense for constraint-expressions,
since they only appear in template declarations.