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

Otherwise, good work on the revision.

From: Liaison <liaison-bounces@lists.isocpp.org> On Behalf Of Andrzej Krzemienski via Liaison
Sent: Thursday, September 30, 2021 9:54 AM
To: Nevin Liber via SG21 <sg21@lists.isocpp.org>; WG14/WG21 liaison mailing list <liaison@lists.isocpp.org>
Cc: Andrzej Krzemienski <akrzemi1@gmail.com>; Gašper Ažman <gasper.azman@gmail.com>
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

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;