-
Notifications
You must be signed in to change notification settings - Fork 782
Description
The category of constraints introduced in a requires expression is not clear. Such as [expr.prim.req.nested]
A nested-requirement can be used to specify additional constraints in terms of local parameters.
we just define three kinds of constraints in [temp.constr.constr]
There are three different kinds of constraints:
- conjunctions,
- disjunctions, and
- atomic constraints.
Consider this example associated with nested-requirement
template<typename T> concept C = requires (T a) {
requires sizeof(a) >0 || true;
};
sizeof(a) >0 || true
is a constraint-expression but not a constraint. In this case, we also cannot know what kind of constraint the expression is. Presumably, the normalization should apply to these expressions to bring them to be the formal constraints.
A similar issue also exists in other kinds of requirements. [expr.prim.req.compound] p1
The immediately-declared constraint ([temp.param]) of the type-constraint for decltype((E)) shall be satisfied.
Again, what's the kind of that constraint? if the type-constraint's constraint-expression has the form E1 || E2
, E1 && E2
or ( E )
. Moreover, "is satisfied" is only defined for constraints, and we only define how the constraint is satisfied in [temp.constr.constr] for three kinds of formal constraints. We might make the normalization apply to all expressions when we want to say the constraint shall be satisfied.