> Immediate context is not defined in the standard, except that we say that
it excludes lambda bodies, as you noticed. Anything that is lexically
within an expression should be considered to be in the immediate context.
If an expression that is in the immediate context triggers the
instantiation of some template defined elsewhere, errors occurring in that
instantiation are not considered to be part of the immediate context of the
original expression.

ok, thank you for confirmation.
A bit weird to me not to have a formal definition of immediate context, but
that would be another topic.

Based on that, my first question concern is still in place.

Let me simplify my previous example.
The new one will lead to lose the dicotomy between true and false result,
but it also allows to better focus on a point:

template<typename T>
requires requires{T::value;}
int func(){return 0;};

int a = func<int>();

Here, the normal form for the constraints related to func<int> is made by a
single atomic constraint whose expression is a requires-expression.

The text in [temp.constr.atomic]-p3 reads

"If substitution results in an invalid type or expression in the immediate
context of the atomic constraint (13.10.3.1), the constraint is not
satisfied."

My point is about the wording "an invalid expression in the immediate
context ...", as in my opinion it may lead to consider the atomic
constraint above to fail because int::value is an invalid expression.
Instead, the requires-expression itself is a valid expression (i.e., it
contains an invalid expression but itself is a valid constant expression
with value false), and [temp.constr.atomic]-p3 should not apply its
consequences.

Of course in this simplified example, the constraint would anyway fail
because the requires-expression gets false (according to
[expr.prim.req.general]-p5).
This is why the example of my previous post was a bit more complex, so that
it turned out to be true instead of false (indeed, complers on godbolt do
not apply [temp.constr.atomic]-p3 looking inside the requires-seq).

Do you agree that the wording may mislead as I suppose ?
Well, I do see that the worst would have been in case the wording was "ANY
invalid expression...", which is not the case, but I still see room for
lack of clearness.
This is why I was proposing to enrich [temp.constr.atomic] in order to
simply discuss the case of a requires-expression (with a note or whatever).

Please, let me know your opinion about it.

>