Date: Wed, 19 Feb 2025 21:08:17 -0500
On Tue, Feb 18, 2025 at 5:21 PM mauro russo <ing.russomauro_at_[hidden]>
wrote:
> Thank you Brian for your thoughts,
>
> sorry for not having been concise, it seemed me to have needed to use the
> background.
> For sure, dealing with multiple questions did not help me.
>
> Anyway, for my first question, let me show the following example
> (accepted by all main compilers: gcc, MVSC, Clang:
> https://godbolt.org/z/9aahnva64
> and I do not regret it)
>
>
> template<typename T>
> concept C = requires{ requires (requires{typename T::type;} || requires{T::value;});
> };
>
> template<C T>
> void f(){};
>
> struct S{
> using type = int;
> };
>
> int main(){
> f<S>();
> }
>
> Here, the normal form for C<S> is made by a single atomic constraint,
> consisting in a requires-expression. In turn, it contains just a single
> nested
> requirement for which the normal form is the logic OR of two atomic
> constraints
> (they are requires-expressions, too), one of which contains an invalid
> expression.
>
> (here above, note that I rely on the fact that no rule from
> [temp.constr.normal] discusses
> any substitution in case of requires-expression for an atomic constraint).
>
> Now the point of my first question is around the formal definition of the
> immediate
> context for the first atomic constraint.
> I do believe that the requires-seq of the external requires-expression is
> not
> part of that immediate context, but I am not sure I can find this from the
> standard text.
> Please, help me.
>
> In particular, my concern is about the fact that [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."
>
> whereas, [expr.prim.req.general]-p5 reads that the requirements in the
> requires-seq
> of a requires-expression are checked one by one, not all soon together.
>
> Unfortuantely, in the example above, in order to highlight the possible
> inconsistency,
> I needed an OR combination so that we don't need the last expression to be
> valid
> in order to get an overall true result for the external
> requires-expression,
> but this also means that I am assuming the immediate context of the nested
> requirement not to contain the ones of the inner requirement-expressions.
>
>
> To summarize, I am just looking for any part of the standard, related to
> any
> formal definition of the immediate context, or specifically associated to
> constraints
> and requires-expressions, so that a clear separation of levels is made in
> hierarchies
> as in my example.
>
> In case some addition should really be needed, I consider the text
> of [temp.deduct.general]-p9 as a possible model. It excludes the body of
> a lambda from any immediate context involving it.
> Such a clarification might be replicated (and adapted) in
> [temp.constr.atomic]
> and/or in [expr.prim.req.general].
>
>
>
>
>
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.
wrote:
> Thank you Brian for your thoughts,
>
> sorry for not having been concise, it seemed me to have needed to use the
> background.
> For sure, dealing with multiple questions did not help me.
>
> Anyway, for my first question, let me show the following example
> (accepted by all main compilers: gcc, MVSC, Clang:
> https://godbolt.org/z/9aahnva64
> and I do not regret it)
>
>
> template<typename T>
> concept C = requires{ requires (requires{typename T::type;} || requires{T::value;});
> };
>
> template<C T>
> void f(){};
>
> struct S{
> using type = int;
> };
>
> int main(){
> f<S>();
> }
>
> Here, the normal form for C<S> is made by a single atomic constraint,
> consisting in a requires-expression. In turn, it contains just a single
> nested
> requirement for which the normal form is the logic OR of two atomic
> constraints
> (they are requires-expressions, too), one of which contains an invalid
> expression.
>
> (here above, note that I rely on the fact that no rule from
> [temp.constr.normal] discusses
> any substitution in case of requires-expression for an atomic constraint).
>
> Now the point of my first question is around the formal definition of the
> immediate
> context for the first atomic constraint.
> I do believe that the requires-seq of the external requires-expression is
> not
> part of that immediate context, but I am not sure I can find this from the
> standard text.
> Please, help me.
>
> In particular, my concern is about the fact that [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."
>
> whereas, [expr.prim.req.general]-p5 reads that the requirements in the
> requires-seq
> of a requires-expression are checked one by one, not all soon together.
>
> Unfortuantely, in the example above, in order to highlight the possible
> inconsistency,
> I needed an OR combination so that we don't need the last expression to be
> valid
> in order to get an overall true result for the external
> requires-expression,
> but this also means that I am assuming the immediate context of the nested
> requirement not to contain the ones of the inner requirement-expressions.
>
>
> To summarize, I am just looking for any part of the standard, related to
> any
> formal definition of the immediate context, or specifically associated to
> constraints
> and requires-expressions, so that a clear separation of levels is made in
> hierarchies
> as in my example.
>
> In case some addition should really be needed, I consider the text
> of [temp.deduct.general]-p9 as a possible model. It excludes the body of
> a lambda from any immediate context involving it.
> Such a clarification might be replicated (and adapted) in
> [temp.constr.atomic]
> and/or in [expr.prim.req.general].
>
>
>
>
>
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.
-- *Brian Bi*
Received on 2025-02-20 02:08:36