C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] D2388R3 (Minimum Contract Support: either No_eval or Eval_and_abort)

From: Andrzej Krzemienski <akrzemi1_at_[hidden]>
Date: Tue, 5 Oct 2021 13:54:58 +0200
Hi Everyone,

One other item has been added in revision 3:
  10. Clarified that contract predicates are not in the immediate context.
See sections {des.imm} and {rat.imm}.

You can find it under the same link:
https://isocpp.org/files/papers/D2388R3.html

and in SG21 Wiki:
https://wiki.edg.com/pub/Wg21telecons2021/SG21/D2388R3.html

Regards,
&rzej;


czw., 30 wrz 2021 o 16:54 Andrzej Krzemienski <akrzemi1_at_[hidden]>
napisaƂ(a):

> Hi Everyone,
>
> This is to let you know that we have a draft of revision 3 of the
> contracts MVP paper:
> https://isocpp.org/files/papers/D2388R3.html
>
> In this revision so far:
>
> 1. Expanded the rationale for the choice of syntax in section {rat.att}.
> Discussed the concerns about confusion with attributes and the potential
> incompatibility with the C programming language.
> 2. Renamed the names of the two translation modes to *Eval_and_abort*
> and *No_eval*, in order to clearly suggest that they control the
> runtime evaluation of the predicates, rather than the checking of syntactic
> correctness at compile time.
> 3. Fixed places where the term "function argument" was used
> incorrectly instead of "function parameter".
> 4. Added an example in section {rat.arg} to illustrate an alternate
> solution with implicitly-const function parameters.
> 5. Removed the normative encouragement for the violation handler to
> output a message to the standard diagnostic output. This is to address
> security concerns.
> 6. Addressed the usage of const_cast in section {rat.arg}.
> 7. Extended the discussion on per-subexpression side effect
> elimination in section {rat.eff}.
> 8. Added section {imp} on implementability, which discusses lists two
> reference implementations.
> 9. Expanded the rationale in section {rat.end} on why we require the
> call to std::abort() (rather than std::terminate()) upon contract
> violation.
>
> We tried to incorporate all feedback we obtained on the reflectors and in
> personal email. Thank you to everyone who contributed to the quality of the
> paper. We are sorry if anything was ignored. This has been a great amount
> of feedback to incorporate.
>
> One thing that is still to be added is the wider discussion of the syntax,
> but it is difficult to keep up with the ongoing reflector discussions.
>
> Any further feedback would be much appreciated.
>
> Regards,
> &rzej;
>
>

Received on 2021-10-05 06:55:14