> template<typename T>
> requires ! requires { T::value; }
> int func() { return 0;}
Thank you Andrew for this simplified case.
Mine one with an || in a nested requirement was quite ugly :-) (post 2882)
I'll report and refer you (if you agree) it in the CWG core issue.
>> 1) in [temp.constr.atomic], avoid the content (requires-seq) of a
>> requires-expression to be considered part of the immediate context for the
>> atomic constraint
Based on no comment, I assume you agree with this part.
>> 2) in [expr.prim.req.nested], avoid the content (constrained-expression)
>> of the nested requirement to be considered part of the immediate context
>> for the nested requirement (in terms of what [expr.prim.req.general]-p5
>> states)
> I think the nested-requirement case is already covered by "Substitution of
> template arguments into a nested-requirement does not result in
> substitution into the constraint-expression other than as specified in
> [temp.constr.constr]." Maybe that could be rephrased in terms of "the
> immediate context" to be more consistent - or maybe that would instead be
> more confusing given the state of that phrase "the immediate context".
Ok, I totally agree. I may likely refer this part in the core issue post.
> I'd consider adding to the note in [temp.deduct.general]/7, which currently
> explains how a function's noexcept-specifier is instantiated, instead of
> during the TAD substitutions in the "deduction substitution loci". A
> template's constraints are a similar thing closely associated with the
> template declaration, but as you're clarifying, the substitution happens in
> a different way. Although in this case checking constraints always happens
> immediately after the TAD substitution (paragraph 5), it would still make
> clear that paragraph 8 "If a [TAD] substitution results in an invalid type
> or expression..." does not apply.
So, you mean in current Note 4. I would prefer a different note, but that's about taste, maybe mine is not the best.However, I do see in p8
"If a substitution results in an invalid type or expression, type deduction fails. An invalid type or expression is one that would be ill-formed, with a diagnostic required, if written in the same context using the substituted arguments."
Maybe the part "with a diagnostic required" is already a way to save consistency, but I am not expert of this section, please let me know your opinion.