[std-discussion] User-provided violation handler for contracts?

[Andrew Giese]

C++20 draft N4762 [dcl.attr.contract.check] seems contradictory to me.
It appears to simultaneously state that handling contract violations is
implementation-defined, but also that a user-provided violation handler is
possible.

Here are the relevant snippets:

The violation handler of a program is a function of type “noexceptopt

function of (lvalue reference to const
std::contract_violation) returning void”, and is specified in an
implementation-defined manner. The
violation handler is invoked when the predicate of a checked contract
evaluates to false (called a contract
violation). There should be no programmatic way of setting or modifying
the violation handler. It is
implementation-defined how the violation handler is established for a
program and how the std::contract_-
violation (16.8.2) argument value is set, except as specified below.

The "as specified below" doesn't quite exist I think.

Later, we see the following;

If a user-provided violation handler exits by throwing an exception and a

contract is violated on a call to a
function with a non-throwing exception specification, then the behavior is
as if the exception escaped the
function body.

This is the first and only mention of a user-provided violation handler. It
seems to imply that it's possible for a user to provide one, when the
previous paragraph suggests it's not possible.

Is this an issue with the standard wording?

[Nicolas Lesser]

Post by Andrew Giese
C++20 draft N4762 [dcl.attr.contract.check] seems contradictory to me.
It appears to simultaneously state that handling contract violations is
implementation-defined, but also that a user-provided violation handler is
possible.
The violation handler of a program is a function of type “noexceptopt

function of (lvalue reference to const
std::contract_violation) returning void”, and is specified in an
implementation-defined manner. The
violation handler is invoked when the predicate of a checked contract
evaluates to false (called a contract
violation). There should be no programmatic way of setting or modifying
the violation handler. It is
implementation-defined how the violation handler is established for a
program and how the std::contract_-
violation (16.8.2) argument value is set, except as specified below.

The "as specified below" doesn't quite exist I think.

You need to continue reading :) The "except as specified below" applies to
the argument of std::contract_violation.

Post by Andrew Giese
Later, we see the following;
If a user-provided violation handler exits by throwing an exception and a

contract is violated on a call to a
function with a non-throwing exception specification, then the behavior
is as if the exception escaped the
function body.

This is the first and only mention of a user-provided violation handler.
It seems to imply that it's possible for a user to provide one, when the
previous paragraph suggests it's not possible.

I can see why you think that, but no, you are wrong. It *is* possible for a
user to provide a violation handler. The standard says it's "implementation
defined". But if it your implementation does provide it, then the only
thing that is not possible is providing it programmatically. For example,
your implementation could take a flag to change it, or use some sort of
scripting language for it.

Post by Andrew Giese
Is this an issue with the standard wording?
--
---
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/.

[Andrew Giese]

Thanks for the reply, Nicolas, that really clears things up.

I guess it's kind of strange the standard went out of the way to discuss
user-defined contract violation handlers when their existence isn't
guaranteed by the standard.

Since the standard states that *user-defined *contract violation handlers
exiting via exception for a function marked noexcept has the same behavior
as throwing from within the body of a noexcept function, is this intended
to distinguish between *implementation-provided* contract violation
handlers? That is, is the standard implying that behavior is undefined (or
implementation defined) if an *implementation-provided * contract violation
handler exits via exception?

Regards,
-Andy

[Nicolas Lesser]

Post by Andrew Giese
Thanks for the reply, Nicolas, that really clears things up.
I guess it's kind of strange the standard went out of the way to discuss
user-defined contract violation handlers when their existence isn't
guaranteed by the standard.

Yeah, it's a bit weird, but there are other places where the standard says
something like that. For example, a standard library could mark a function
`constexpr` that the standard specifies as not constexpr, because it
follows the as-if rule. But the standard has a paragraph that says that
implementations are not allowed to do that. You can imagine it like
implementation-defined behavior, but with restrictions.

Post by Andrew Giese
Since the standard states that *user-defined *contract violation handlers
exiting via exception for a function marked noexcept has the same behavior
as throwing from within the body of a noexcept function, is this intended
to distinguish between *implementation-provided* contract violation
handlers? That is, is the standard implying that behavior is undefined (or
implementation defined) if an *implementation-provided * contract
violation handler exits via exception?

"user-defined" and implementation provided violations handlers are the same
thing. I have no idea why "user-defined" is used here; it's never defined
for violations handlers and seems unnecessary (after all, every violation
handler is implementation defined; the standard doesn't specify one). If a
violation handler throws, it is as-if the exception is thrown from the
body, so in the case of a noexcept function, std::terminate is called.

Post by Andrew Giese
Regards,
-Andy
--
---
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/.

[Ville Voutilainen]

Post by Andrew Giese
Thanks for the reply, Nicolas, that really clears things up.
I guess it's kind of strange the standard went out of the way to discuss user-defined contract violation handlers when their existence isn't guaranteed by the standard.

Yeah, it's a bit weird, but there are other places where the standard says something like that. For example, a standard library could mark a function `constexpr` that the standard specifies as not constexpr, because it follows the as-if rule. But the standard has a paragraph that says that implementations are not allowed to do that. You can imagine it like implementation-defined behavior, but with restrictions.

It doesn't follow the as-if rule. Whether a function is constexpr is observable.

[Nicolas Lesser]

It is observable but it still follows as-if, because a constexpr function
can do everything a non-constexpr function can.

On Mon, Sep 24, 2018 at 8:09 PM Ville Voutilainen <

Post by Andrew Giese

Post by Nicolas Lesser

Post by Andrew Giese
Thanks for the reply, Nicolas, that really clears things up.
I guess it's kind of strange the standard went out of the way to

discuss user-defined contract violation handlers when their existence isn't
guaranteed by the standard.

Post by Nicolas Lesser
Yeah, it's a bit weird, but there are other places where the standard

says something like that. For example, a standard library could mark a
function `constexpr` that the standard specifies as not constexpr, because
it follows the as-if rule. But the standard has a paragraph that says that
implementations are not allowed to do that. You can imagine it like
implementation-defined behavior, but with restrictions.
It doesn't follow the as-if rule. Whether a function is constexpr is observable.
--
---
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/.

[Ville Voutilainen]

It is observable but it still follows as-if, because a constexpr function can do everything a non-constexpr function can.

That's not what the as-if rule means.

[Nicolas Lesser]

Post by Nicolas Lesser
It is observable but it still follows as-if, because a constexpr

function can do everything a non-constexpr function can.
That's not what the as-if rule means.

What does it mean then? The as-if rule applies to behavior specified by the
standard, not anything else. It doesn't matter that some extra behavior is
observable, that's an implementation detail which the standard doesn't care
about.

How does specifying a function with constexpr change observable behavior? I
don't think you can use SFINAE to see a change in behavior.

--
---
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/.

[Andrew Tomazos]

int f();

int main() {
constexpr auto x = f();
}

The above program is ill-formed (diagnostic required). If f were changed
to constexpr, the above program would not emit the required diagnostic.

On Mon, Sep 24, 2018, 8:47 PM Ville Voutilainen <

Post by Nicolas Lesser
It is observable but it still follows as-if, because a constexpr

function can do everything a non-constexpr function can.
That's not what the as-if rule means.

What does it mean then? The as-if rule applies to behavior specified by
the standard, not anything else. It doesn't matter that some extra behavior
is observable, that's an implementation detail which the standard doesn't
care about.
How does specifying a function with constexpr change observable behavior?
I don't think you can use SFINAE to see a change in behavior.

--
---
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
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Nicolas Lesser]

How is that diagnostic *required*? Does the standard say that a function
without constexpr shall not be invocable in a constexpr context (it does,
but we're ignoring that rule for the moment)?

No, the as-if rule only applies to behavior that the standard specifies. It
just says that the function is required to do X. If the function is marked
constexpr, then you get X plus a Y (compile time computation). As far as
the standard is concerned, the implementation is conforming. After all, it
does X, as the standard specifies. That the implementation also allows Y is
an implementation detail that falls under the allowed extensions of a
conforming implementation.

Post by Andrew Tomazos
int f();
int main() {
constexpr auto x = f();
}
The above program is ill-formed (diagnostic required). If f were changed
to constexpr, the above program would not emit the required diagnostic.

On Mon, Sep 24, 2018, 8:47 PM Ville Voutilainen <

Post by Nicolas Lesser
It is observable but it still follows as-if, because a constexpr

function can do everything a non-constexpr function can.
That's not what the as-if rule means.

What does it mean then? The as-if rule applies to behavior specified by
the standard, not anything else. It doesn't matter that some extra behavior
is observable, that's an implementation detail which the standard doesn't
care about.
How does specifying a function with constexpr change observable behavior?
I don't think you can use SFINAE to see a change in behavior.

--
---
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
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
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
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Jens Maurer]

The fundamental question seems to be whether it is observable
that some function is declared constexpr.
The answer clearly is "yes, of course":

#include <iostream>

constexpr int c(short) { return 4; } // needed to have at least one valid instantiation

/* constexpr */ int c(int) { return 5; }

template<int N> struct C { };

template<class T>
void f(T x, C<c(T())> * = nullptr)
{
std::cout << "constexpr" << std::endl;
}

void f(...)
{
std::cout << "not constexpr" << std::endl;
}

int main()
{
f(1);
}


If you add "constexpr" for c(int), you'll get a different output from
the program.

Jens

How is that diagnostic *required*? Does the standard say that a function without constexpr shall not be invocable in a constexpr context (it does, but we're ignoring that rule for the moment)?
No, the as-if rule only applies to behavior that the standard specifies. It just says that the function is required to do X. If the function is marked constexpr, then you get X plus a Y (compile time computation). As far as the standard is concerned, the implementation is conforming. After all, it does X, as the standard specifies. That the implementation also allows Y is an implementation detail that falls under the allowed extensions of a conforming implementation.
int f();
int main() {
constexpr auto x = f();
}
The above program is ill-formed (diagnostic required). If f were changed to constexpr, the above program would not emit the required diagnostic.

It is observable but it still follows as-if, because a constexpr function can do everything a non-constexpr function can.

That's not what the as-if rule means.
What does it mean then? The as-if rule applies to behavior specified by the standard, not anything else. It doesn't matter that some extra behavior is observable, that's an implementation detail which the standard doesn't care about.
How does specifying a function with constexpr change observable behavior? I don't think you can use SFINAE to see a change in behavior.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
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.
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.
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Nicolas Lesser]

I should have guessed that you can use SFINAE tricks to see a difference;
sorry :(

Well, now my question is: Why does that paragraph exist if it also already
violates the as-if rule?

Post by Jens Maurer
The fundamental question seems to be whether it is observable
that some function is declared constexpr.
#include <iostream>
constexpr int c(short) { return 4; } // needed to have at least one valid instantiation
/* constexpr */ int c(int) { return 5; }
template<int N> struct C { };
template<class T>
void f(T x, C<c(T())> * = nullptr)
{
std::cout << "constexpr" << std::endl;
}
void f(...)
{
std::cout << "not constexpr" << std::endl;
}
int main()
{
f(1);
}
If you add "constexpr" for c(int), you'll get a different output from
the program.
Jens

Post by Nicolas Lesser
How is that diagnostic *required*? Does the standard say that a function

without constexpr shall not be invocable in a constexpr context (it does,
but we're ignoring that rule for the moment)?

Post by Nicolas Lesser
No, the as-if rule only applies to behavior that the standard specifies.

It just says that the function is required to do X. If the function is
marked constexpr, then you get X plus a Y (compile time computation). As
far as the standard is concerned, the implementation is conforming. After
all, it does X, as the standard specifies. That the implementation also
allows Y is an implementation detail that falls under the allowed
extensions of a conforming implementation.

Post by Nicolas Lesser
int f();
int main() {
constexpr auto x = f();
}
The above program is ill-formed (diagnostic required). If f were

changed to constexpr, the above program would not emit the required
diagnostic.

Post by Nicolas Lesser
On Tue, Sep 25, 2018 at 5:03 AM Nicolas Lesser <
On Mon, Sep 24, 2018, 8:47 PM Ville Voutilainen <
On Mon, 24 Sep 2018 at 21:12, Nicolas Lesser <

Post by Nicolas Lesser
It is observable but it still follows as-if, because a

constexpr function can do everything a non-constexpr function can.

Post by Nicolas Lesser
That's not what the as-if rule means.
What does it mean then? The as-if rule applies to behavior

specified by the standard, not anything else. It doesn't matter that some
extra behavior is observable, that's an implementation detail which the
standard doesn't care about.

Post by Nicolas Lesser
How does specifying a function with constexpr change observable

behavior? I don't think you can use SFINAE to see a change in behavior.

Post by Nicolas Lesser
--
---
You received this message because you are subscribed to the

Google Groups "ISO C++ Standard - Discussion" group.

Post by Nicolas Lesser
To unsubscribe from this group and stop receiving emails
To post to this group, send email to
Visit this group at

https://groups.google.com/a/isocpp.org/group/std-discussion/.

Post by Nicolas Lesser
--
---
You received this message because you are subscribed to the

Google Groups "ISO C++ Standard - Discussion" group.

Post by Nicolas Lesser
To unsubscribe from this group and stop receiving emails from
Visit this group at

https://groups.google.com/a/isocpp.org/group/std-discussion/.

Post by Nicolas Lesser
--
---
You received this message because you are subscribed to the Google

Groups "ISO C++ Standard - Discussion" group.

Post by Nicolas Lesser
To unsubscribe from this group and stop receiving emails from it,
Visit this group at

https://groups.google.com/a/isocpp.org/group/std-discussion/.

Post by Nicolas Lesser
--
---
You received this message because you are subscribed to the Google

Groups "ISO C++ Standard - Discussion" group.

Post by Nicolas Lesser
To unsubscribe from this group and stop receiving emails from it, send
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
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Jens Maurer]

I should have guessed that you can use SFINAE tricks to see a difference; sorry :(
Well, now my question is: Why does that paragraph exist if it also already violates the as-if rule?

Which paragraph? The one allowing library implementers to add "constexpr"
in cases where the standard doesn't require it?

That paragraph does not violate the as-if rule; the as-if rule is
entirely a dead end for this discussion.

The point is that users of the standard library must not rely
on the absence of "constexpr" for standard library functions
that are not specified as "constexpr", for example by writing
"clever" programs such as mine below. Yes, for "normal" uses
of the standard library, this does not matter. The point is that
the C++ standard needs to cover also the "non-normal" uses, if
only by saying "don't do that".

Jens

The fundamental question seems to be whether it is observable
that some function is declared constexpr.
#include <iostream>
constexpr int c(short) { return 4; } // needed to have at least one valid instantiation
/* constexpr */ int c(int) { return 5; }
template<int N> struct C { };
template<class T>
void f(T x, C<c(T())> * = nullptr)
{
std::cout << "constexpr" << std::endl;
}
void f(...)
{
std::cout << "not constexpr" << std::endl;
}
int main()
{
f(1);
}
If you add "constexpr" for c(int), you'll get a different output from
the program.

[Ville Voutilainen]

Post by Jens Maurer

I should have guessed that you can use SFINAE tricks to see a difference; sorry :(
Well, now my question is: Why does that paragraph exist if it also already violates the as-if rule?

Which paragraph? The one allowing library implementers to add "constexpr"
in cases where the standard doesn't require it?

Last I checked, such a paragraph does not exist, so I don't know what
paragraph we are talking about. We
say in [constexpr.functions]/1 that the library is _not_ allowed to
add constexpr.

[Andrew Tomazos]

Post by Nicolas Lesser
How is that diagnostic *required*?

The implementation is required to emit a diagnostic if a program violates a
diagnosable rule. See [intro.compliance]
http://eel.is/c++draft/intro.compliance

Post by Nicolas Lesser
Does the standard say that a function without constexpr shall not be
invocable in a constexpr context (it does, but we're ignoring that rule for
the moment)?

Yes, that's a diagnosable rule.

Post by Nicolas Lesser
No, the as-if rule only applies to behavior that the standard specifies.
It just says that the function is required to do X. If the function is
marked constexpr, then you get X plus a Y (compile time computation). As
far as the standard is concerned, the implementation is conforming. After
all, it does X, as the standard specifies. That the implementation also
allows Y is an implementation detail that falls under the allowed
extensions of a conforming implementation.

Post by Andrew Tomazos
int f();
int main() {
constexpr auto x = f();
}
The above program is ill-formed (diagnostic required). If f were changed
to constexpr, the above program would not emit the required diagnostic.

On Mon, Sep 24, 2018, 8:47 PM Ville Voutilainen <

Post by Nicolas Lesser
It is observable but it still follows as-if, because a constexpr

function can do everything a non-constexpr function can.
That's not what the as-if rule means.

What does it mean then? The as-if rule applies to behavior specified by
the standard, not anything else. It doesn't matter that some extra behavior
is observable, that's an implementation detail which the standard doesn't
care about.
How does specifying a function with constexpr change observable
behavior? I don't think you can use SFINAE to see a change in behavior.

--
---
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
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
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
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
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.