Discussion:
Contract violation during constant expression evaluation
(too old to reply)
Alberto Barbati
2018-11-16 09:34:28 UTC
Permalink
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
--
---
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 email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Nicolas Lesser
2018-11-16 09:43:35 UTC
Permalink
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/.
--
---
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 email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Alberto Barbati
2018-11-16 09:57:02 UTC
Permalink
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.
--
---
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 email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Continue reading on narkive:
Loading...