On Thu, Feb 20, 2025 at 4:14 PM mauro russo <ing.russomauro_at_[hidden]>
wrote:

> > 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.
>
>>
I see what you're saying. Perhaps any nested SFINAE contexts, i.e. an
atomic constraint or the body of a requires-expression, should be
considered to not be in the immediate context of the enclosing expression,
so that only the innermost enclosing SFINAE context is considered to be
unsatisfied, or evaluates to false. I think this could be a viable core
issue.

-- 
*Brian Bi*