[std-discussion] Contract violation during constant expression evaluation

[Alberto Barbati]

Hi,

what is the effect of a contract violation during constant expression
evaluation? The only relevant part I found in N4778 is in
[dcl.attr.contract.check]/4
<http://eel.is/c++draft/dcl.attr.contract.check#4>:

During constant expression evaluation (7.7), only predicates of checked

contracts are evaluated. In other contexts, it is unspecified whether the
predicate for a contract that is not checked under the current build level
is evaluated; if the predicate of such a contract would evaluate to false,
the behavior is undefined.

However, this paragraph only says which contracts are checked, but does not
mention the effects of a violation *during constant evaluation*. Therefore
I have to assume that a violation handler of some kind has to be called, as
described in the subsequent paragraph. However, the handler described there
is not a constexpr function, so it cannot be called during constant
evaluation! Mind that std::contract_violation is not a literal type and
doesn't have constexpr members, so it is not possible nor meaningful to
have a constexpr handler. I believe the intent here is to just make the
program ill-formed whenever a contract is violated during constant
evaluation, but if that's true, I think we should say that explicitly. If
that's not the intent, we might want to clarify what the intent is.

On a side note, at the present moment the only way for a user-provided
constexpr function to produce some kind of diagnostic is through a
static_assert declaration, which only accepts a string literal and issues a
diagnostic while also making the program ill-formed. Would it be
feasible/desirable to have a magic library function, specifically designed
to be used in constexpr functions and able to issue a compile-time
diagnostic from a compile-time constructed string and without making the
program ill-formed? I believe that it would greatly help debugging
constexpr functions.

My two eurocent,

Alberto

[Nicolas Lesser]

Post by Alberto Barbati
Hi,
what is the effect of a contract violation during constant expression
evaluation? The only relevant part I found in N4778 is in
[dcl.attr.contract.check]/4
During constant expression evaluation (7.7), only predicates of checked

contracts are evaluated. In other contexts, it is unspecified whether the
predicate for a contract that is not checked under the current build level
is evaluated; if the predicate of such a contract would evaluate to false,
the behavior is undefined.

However, this paragraph only says which contracts are checked, but does
not mention the effects of a violation *during constant evaluation*.
Therefore I have to assume that a violation handler of some kind has to be
called, as described in the subsequent paragraph. However, the handler
described there is not a constexpr function, so it cannot be called during
constant evaluation! Mind that std::contract_violation is not a literal
type and doesn't have constexpr members, so it is not possible nor
meaningful to have a constexpr handler. I believe the intent here is to
just make the program ill-formed whenever a contract is violated during
constant evaluation, but if that's true, I think we should say that
explicitly. If that's not the intent, we might want to clarify what the
intent is.

The intent is that the program is ill-formed. [expr.const]p2:

[expr is a core constant expression unless it evaluates]

Post by Alberto Barbati
- a checked contract ([dcl.attr.contract]) whose predicate evaluates to

false;

Post by Alberto Barbati
On a side note, at the present moment the only way for a user-provided
constexpr function to produce some kind of diagnostic is through a
static_assert declaration, which only accepts a string literal and issues a
diagnostic while also making the program ill-formed. Would it be
feasible/desirable to have a magic library function, specifically designed
to be used in constexpr functions and able to issue a compile-time
diagnostic from a compile-time constructed string and without making the
program ill-formed? I believe that it would greatly help debugging
constexpr functions.

Like a logging function at compile time? I don't know what to think about
that :)

Post by Alberto Barbati
My two eurocent,
Alberto
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Alberto Barbati]

Il giorno venerdì 16 novembre 2018 10:43:50 UTC+1, Nicolas Lesser ha

Post by Nicolas Lesser

Post by Alberto Barbati
Hi,
what is the effect of a contract violation during constant expression
evaluation? The only relevant part I found in N4778 is in
[dcl.attr.contract.check]/4
During constant expression evaluation (7.7), only predicates of checked

contracts are evaluated. In other contexts, it is unspecified whether the
predicate for a contract that is not checked under the current build level
is evaluated; if the predicate of such a contract would evaluate to false,
the behavior is undefined.

However, this paragraph only says which contracts are checked, but does
not mention the effects of a violation *during constant evaluation*.
Therefore I have to assume that a violation handler of some kind has to be
called, as described in the subsequent paragraph. However, the handler
described there is not a constexpr function, so it cannot be called during
constant evaluation! Mind that std::contract_violation is not a literal
type and doesn't have constexpr members, so it is not possible nor
meaningful to have a constexpr handler. I believe the intent here is to
just make the program ill-formed whenever a contract is violated during
constant evaluation, but if that's true, I think we should say that
explicitly. If that's not the intent, we might want to clarify what the
intent is.

[expr is a core constant expression unless it evaluates]

Post by Alberto Barbati
- a checked contract ([dcl.attr.contract]) whose predicate evaluates to

false;

Ah, yes! Thanks for the pointer. It's a bit convoluted, though... Since we
are evaluating a constant expression [dcl.attr.contract.check]/4 says which
contracts are checked, but, as soon as one of the selected contracts is
violated, [expr.const]/2 says the expression is no longer constant, so (the
relevant part of) [dcl.attr.contract.check]/4 no longer applies. Moreover,
the program is ill-formed not because the contract is violated, but because
the expression (which is not a core constant expression) is probably used
in a context that requires a core constant expression. Maybe it's just me,
but it I believe the wording could be improved somehow.

Post by Nicolas Lesser

Post by Alberto Barbati
On a side note, at the present moment the only way for a user-provided
constexpr function to produce some kind of diagnostic is through a
static_assert declaration, which only accepts a string literal and issues a
diagnostic while also making the program ill-formed. Would it be
feasible/desirable to have a magic library function, specifically designed
to be used in constexpr functions and able to issue a compile-time
diagnostic from a compile-time constructed string and without making the
program ill-formed? I believe that it would greatly help debugging
constexpr functions.

Like a logging function at compile time? I don't know what to think about
that :)

Yes, exactly that. Of course, a program would use such a function only
while debugging the compilation and remove it eventually. Or leave it,
since it would't have any effect at runtime.