P0542R5 Support for contract based programming in C++ #2151

jensmaurer · 2018-06-10T20:58:06Z

zygoloid · 2018-06-14T23:04:11Z

source/basic.tex

@@ -550,6 +550,15 @@
 requirement applies recursively)\footnote{\ref{dcl.fct.default}
 describes how default argument names are looked up.}; and

+\item if \tcode{D} is a function that


This "is a function" restriction is new, and appears to be incorrect for the "invokes a function with a precondition" part. Perhaps:

if D invokes a function with a precondition, or is a function that contains an assertion or has a postcondition, [...]

The "pure" model says preconditions are checked in the caller (so we need to account for that), but we have otherwise drafted wording that assumes (under as-if) that preconditions are actually evaluated in the callee. So, I think we should actually care for both places where precondition checking code could be emitted.

I agree. However, this appears to be a normative change relative to the wording we were given, so can you send an email to the core reflector to make sure this won't surprise anyone?

zygoloid · 2018-06-14T23:05:35Z

source/basic.tex

+contains an assertion,
+has a postcondition,
+or invokes a function with a precondition,
+the conditions under which each definition of \tcode{D}


This "the conditions under which" phrasing is awkward. Presumably the intent is that an implementation can say that some combinations are allowed and some are not, so we can't just say:

[...] it is implementation-defined whether all definitions of D shall be translated using the same build level and violation continuation mode.

?

Yes, it's my understanding that the implementation has to actually state the list of conditions, and the authors hope (in vain?) it's not "always", but something more modular and user-friendly.

I've rephrased a bit more; it's now less awkward and still talks about "conditions".

zygoloid · 2018-06-14T23:10:18Z

source/declarations.tex

@@ -4239,3 +4240,414 @@
 could have the same address as \tcode{buckets}
 if their respective types are all empty.
 \end{example}
+
+\rSec2[dcl.attr.contract]{Contract attributes}%


We keep the subclauses of [dcl.attr] in alphabetical order. (So far that's been by attribute name, but the contract attributes throw a spanner in the works here.)

I'm not sure what the best answer is here.

"We keep the subclauses of [dcl.attr] in alphabetical order."
Ah, that wasn't clear to me. But yes, the current list looks alphabetical.

Sort according to "contract" maybe? We already sort "likely" and "unlikely" under "likelihood".
@zygoloid, awaiting your answer before actually doing the move.

Sure, let's sort by heading name.

zygoloid · 2018-06-14T23:11:02Z

source/declarations.tex

+\begin{bnf}
+\nontermdef{contract-attribute-specifier}\br
+  \terminal{[} \terminal{[} \terminal{expects} \opt{contract-level} \terminal{:} conditional-expression \terminal{]} \terminal{]}\br
+  \terminal{[} \terminal{[} \terminal{ensures} \opt{contract-level} \terminal{:} \opt{identifier} \terminal{:} conditional-expression \terminal{]} \terminal{]}\br


There's a stray colon here before the identifier.

Uh, right.
So, this is a "fixup" against the original paper transcription. I'd really like to move that commit as a "fixup" right after the original paper application, but how do I do that given that I'm not supposed to force-push?

What you did is fine, I'll figure out which commit it's a fixup for when I do the merging. Or if you're going to force push anyway to rebase and pick up the new header names table, you could merge it into the original paper commit yourself.

zygoloid · 2018-06-14T23:17:18Z

source/declarations.tex

+\end{note}
+
+\pnum
+The predicate of a contract is potentially evaluated\iref{basic.def.odr}.


Move this sentence to the end of paragraph 5. Also, we should convert it to a note, since this follows from the definition of "potentially evaluated".

Agreed; fixed.

zygoloid · 2018-06-14T23:39:29Z

source/declarations.tex

+setting or modifying the violation handler.
+It is \impldef{argument for violation handler}
+how the violation handler is established for a program and
+how the \tcode{std::contract_violation} argument value is set.


I think we need an "except as specified below" here, since we're about to give some rules that dictate how parts of the contract_violation argument value are set.

Agreed; also added a cross-reference to [support.contract.cviol].

zygoloid · 2018-06-14T23:45:30Z

source/derived.tex

+}
+
+struct C : A, B {
+  virtual void g();             // ill-formed, no diagnostic required


Wait, why is this "no diagnostic required"? The overrider doesn't satisfy the conditions of the ODR, and won't always produce the same value. This is just ill-formed, isn't it?

Right, fixed.

zygoloid · 2018-06-14T23:57:45Z

source/templates.tex

+into the templated function, variable, or class
+are two declarations of the same entity.
+An \grammarterm{explicit-instantiation} of a function template
+shall not specify a contract condition\iref{dcl.attr.contract}.


This is not an appropriate place for this rule (it's placed between a normative rule and its note and example). In fact, we often place such rules with the rules about the prohibited thing, not in the explicit instantiation rules. For example, [dcl.stc] disallows storage classes in explicit instantiations, and [except.spec] gives the rules for noexcept in explicit instantiations. But I would note that some other related rules are in [temp.explicit]p1: "An explicit instantiation of a function template, member function of a class template, or variable template shall not use the inline or constexpr specifiers." (And I'm not sure where we disallow an explicit instantiation from having default arguments...)

But this is also redundant. [dcl.attr.grammar]p5 says "No attribute-specifier-seq shall appertain to an explicit instantiation". So I think we should either drop this change or convert it to a note in p1.

Removed due to redundancy. I'm not adding a note; we should decide whether we want the "explicit instantiation" restriction in [temp.explicit] or where the other feature is defined, and consistently put notes in the "other" places. See #2188, for a later time.

zygoloid · 2018-06-15T00:00:02Z

source/exceptions.tex

@@ -1028,6 +1028,19 @@
 \tcode{std::atexit} or \tcode{std::at_quick_exit}
 exits via an exception\iref{support.start.term}, or

+\item%
+when evaluation of a predicate\iref{dcl.attr.contract}


"a predicate" -> "the predicate of a contract"

zygoloid · 2018-06-15T00:01:04Z

source/lib-intro.tex

@@ -1013,41 +1013,46 @@
 {llll}
 \topline
 \tcode{<algorithm>} &
+\tcode{<fstream>} &


This needs merging / rebasing.

Do you want me to rebase (with force-push)? That is my preference; i have no idea what "merge" would do to me.

Yes, pushing with --force-with-lease seems fine here. (I think that will probably do bad things to github's comment tracking, though I suppose there's only one way to find out.)

zygoloid · 2018-06-16T01:12:39Z

All looks good so far. Thanks!

jensmaurer · 2018-06-17T07:32:55Z

Ok, pushed using --force-with-lease.

Also move rules on virtual functions to [class.virtual]. Rephase assertion checking along pre/postcondition checking.

as per the definition in [basic.def.odr], so turn the redundant normative statement into a note.

…ment

…edicate.

given that [dcl.attr.grammar] already prohibits attribute-specifier-seqs for an explicit instantiation.

jensmaurer added this to the post-2018-06 milestone Jun 10, 2018

zygoloid requested changes Jun 15, 2018

View reviewed changes

jensmaurer added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jun 15, 2018

jensmaurer mentioned this pull request Jun 16, 2018

Typo in Rapperswil CWG motion 14 #2192

Closed

jensmaurer force-pushed the motions-2018-06-cwg-14 branch from 6350c0f to 5f6072d Compare June 17, 2018 07:32

jensmaurer removed the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Jun 17, 2018

jensmaurer added 17 commits June 18, 2018 17:57

P0542R5 Support for contract based programming in C++

fa926f8

[dcl.attr.contract] Avoid duplication of 'renaming' in enumeration

f28517a

[except.terminate] Add contract violation with continuation mode off

19d07de

[dcl.attr.contract] Rephrase comments in examples

ac60314

[basic.def.odr] Rephrase build level and continuation mode requirements

42019fd

[dcl.attr.contract] Reorder paragraphs for more coherence.

0fc2af6

Also move rules on virtual functions to [class.virtual]. Rephase assertion checking along pre/postcondition checking.

[basic.def.odr] Rephrase ODR rule for contracts

da24c5d

[dcl.attr.contract] Predicates of a contract are potentially evaluated,

77579d2

as per the definition in [basic.def.odr], so turn the redundant normative statement into a note.

[dcl.attr.contract] Clarify rules on std::contract_violation

072f42d

[dcl.attr.contract] Clarify that assertions may apply to a null state…

87c3c20

…ment

[dcl.attr.contract] Permit modifications of temporaries within the pr…

2930dc5

…edicate.

[dcl.attr.contract] Clarify evaluation of non-checked contracts

0cd3f3d

[dcl.attr.contract] Fix sentence defining violation handler

ca0d62c

[class.virtual] Fix comment in example

a7a0e11

[temp.explicit] Remove redundant rules for contracts

f2f60fd

given that [dcl.attr.grammar] already prohibits attribute-specifier-seqs for an explicit instantiation.

[except.terminate] Clarify evaluation of a contract

463ab8d

[dcl.attr.contract] Move according to alphabetical sorting of headings

913c83a

zygoloid force-pushed the motions-2018-06-cwg-14 branch from 5f6072d to 913c83a Compare June 19, 2018 00:59

zygoloid approved these changes Jun 19, 2018

View reviewed changes

zygoloid merged commit 8f613b7 into master Jun 19, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

P0542R5 Support for contract based programming in C++ #2151

P0542R5 Support for contract based programming in C++ #2151

jensmaurer commented Jun 10, 2018

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 16, 2018

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 16, 2018

jensmaurer Jun 17, 2018

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 16, 2018

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018 •

edited

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 14, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 15, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 15, 2018

jensmaurer Jun 15, 2018

zygoloid Jun 16, 2018

zygoloid commented Jun 16, 2018

jensmaurer commented Jun 17, 2018

P0542R5 Support for contract based programming in C++ #2151

P0542R5 Support for contract based programming in C++ #2151

Conversation

jensmaurer commented Jun 10, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jensmaurer Jun 15, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zygoloid commented Jun 16, 2018

jensmaurer commented Jun 17, 2018

jensmaurer Jun 15, 2018 •

edited