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:50:14 +0200
czw., 30 wrz 2021 o 18:17 Ben Craig <ben.craig_at_[hidden]> napisał(a):

> In 7.19, I think you need to s/hosted/freestanding. Hosted has a standard
> diagnostic stream (stderr), freestanding does not.
>

Thank you :)
Fixed.

Regards,
&rzej;


>
> Otherwise, good work on the revision.
>
>
>
> *From:* Liaison <liaison-bounces_at_[hidden]> *On Behalf Of *Andrzej
> Krzemienski via Liaison
> *Sent:* Thursday, September 30, 2021 9:54 AM
> *To:* Nevin Liber via SG21 <sg21_at_[hidden]>; WG14/WG21 liaison
> mailing list <liaison_at_[hidden]>
> *Cc:* Andrzej Krzemienski <akrzemi1_at_[hidden]>; Gašper Ažman <
> gasper.azman_at_[hidden]>
> *Subject:* [EXTERNAL] [wg14/wg21 liaison] D2388R3 (Minimum Contract
> Support: either No_eval or Eval_and_abort)
>
>
>
> 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
> <https://urldefense.com/v3/__https:/isocpp.org/files/papers/D2388R3.html__;!!FbZ0ZwI3Qg!8I0V5mztV_Uj3PXkfEv7JJfIUxyzJk6NIy04QdGyax4gfTCFnjm3J_krWR5r$>
>
>
>
> 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:50:30