Date: Tue, 25 Feb 2025 16:22:56 +0100
>> Since CWG2461 there's no equivalent of [expr.prim.req.general]/5 for
>> atomic constraints. (Maybe there should be; I'm not entirely convinced
>> the removal was intentional.)
> [temp.constr.atomic] p3 says the satisfaction check includes
> the substitution step, so I think CWG2461 didn't remove anything.
Thank you Jens for the clarification.
I hope you may help also on the initial topic
about the statement from [temp.res.general]-p(6.4) ?
Here below the thread on it wih M.P. :
>From me:
>>> The point is: for a requires-expression that case (not
>>> possible to satisfy) is always IFNDR, whereas for a
>>> constraint-expression it reads that IFNDR is in place
>>> only if no satisfation check is actually performed.
>>> I don't see what is the rationale behind it.
>>> It would make sense only for errors that are not
>>> in the immediate context, because in this case
>>> a satisfation check leads to an ill-formed notification
>>> by compilers.
>>> However, if the error that causes the lack of satisfaction
>>> is in the immediate context, then the constraint is just
>>> not satisfied (based on [temp.constr.atomic]-p3),
>>> and I don't see any motivation not to fall in IFNDR.
>>> Let me also additionally notice
>>> that [temp.res.general]-p6+p(6.4)
>>> does not indicate any difference between templated
>>> or non-templated entities,
>>> whereas [expr.prim.req.general] - p5 better clarifies
>>> that an always-false expression in a non-templated
>>> entity is IF instead of IFNDR.
>>> Even in this perspective, [temp.res.general]-p6+p(6.4)
>>> is more relaxed as it requires IFNDR,
>>> not IF (for non-templated entities).
>From M.P.:
>> [temp.res.general]/6.4 is not talking about substitution failure,
>> it's talking about satisfaction checks of atomic constraints
>> being ill-formed (a situation that arises when substitution
>> succeeds but does not produce a constant expression of
>> type bool). If a satisfaction check of A is performed, then
>> the program is just ill-formed (diagnostic required).
>From me:
> Thank you for this contribution.
> I wonder the term 'satisfaction check' is just twice in
> the standard, both occurrences in [temp.res.general]/6.4.
> Might you please help me with any reference to other parts
> supporting this terminology ?
>> atomic constraints. (Maybe there should be; I'm not entirely convinced
>> the removal was intentional.)
> [temp.constr.atomic] p3 says the satisfaction check includes
> the substitution step, so I think CWG2461 didn't remove anything.
Thank you Jens for the clarification.
I hope you may help also on the initial topic
about the statement from [temp.res.general]-p(6.4) ?
Here below the thread on it wih M.P. :
>From me:
>>> The point is: for a requires-expression that case (not
>>> possible to satisfy) is always IFNDR, whereas for a
>>> constraint-expression it reads that IFNDR is in place
>>> only if no satisfation check is actually performed.
>>> I don't see what is the rationale behind it.
>>> It would make sense only for errors that are not
>>> in the immediate context, because in this case
>>> a satisfation check leads to an ill-formed notification
>>> by compilers.
>>> However, if the error that causes the lack of satisfaction
>>> is in the immediate context, then the constraint is just
>>> not satisfied (based on [temp.constr.atomic]-p3),
>>> and I don't see any motivation not to fall in IFNDR.
>>> Let me also additionally notice
>>> that [temp.res.general]-p6+p(6.4)
>>> does not indicate any difference between templated
>>> or non-templated entities,
>>> whereas [expr.prim.req.general] - p5 better clarifies
>>> that an always-false expression in a non-templated
>>> entity is IF instead of IFNDR.
>>> Even in this perspective, [temp.res.general]-p6+p(6.4)
>>> is more relaxed as it requires IFNDR,
>>> not IF (for non-templated entities).
>From M.P.:
>> [temp.res.general]/6.4 is not talking about substitution failure,
>> it's talking about satisfaction checks of atomic constraints
>> being ill-formed (a situation that arises when substitution
>> succeeds but does not produce a constant expression of
>> type bool). If a satisfaction check of A is performed, then
>> the program is just ill-formed (diagnostic required).
>From me:
> Thank you for this contribution.
> I wonder the term 'satisfaction check' is just twice in
> the standard, both occurrences in [temp.res.general]/6.4.
> Might you please help me with any reference to other parts
> supporting this terminology ?
Received on 2025-02-25 15:23:08